Date: Wed, 28 Aug 2024 12:00:27 +0000
> We were in a situation where I could validly post a bug report to the third-party library "your code is non-conforming; please fix it". In the future, we are in a situation where I can't do that anymore, and I need to post a bug report to my compiler vendor "#pragma once is broken".
That's does sound a lot like bullying developers with the standard in order to change their code to your preferred way of working.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jens Maurer via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, August 28, 2024 12:34:01 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jens Maurer <jens.maurer_at_[hidden]>
Subject: Re: [std-proposals] Revising #pragma once
On 28/08/2024 01.54, Arthur O'Dwyer via Std-Proposals wrote:
> (Of course it's possible that their answer is "/Nothing/ works in my environment, period; I will /never ever/ switch from #ifndef to #pragma once." In that case, the problem is solved, because we don't need to make GCC handle #pragma once in their environment — they'll never use it, so they'll never notice that it's missing.)
Not all code that wants to be compiled in a given environment
is necessarily home-grown. Maybe a third-party code provider
has decided to switch to "#pragma once" because it has been
standardized. However, now there is an expectation that it
works reliably everywhere, and we've seen good rationale it
doesn't.
We were in a situation where I could validly post a bug report
to the third-party library "your code is non-conforming; please
fix it". In the future, we are in a situation where I can't do
that anymore, and I need to post a bug report to my compiler
vendor "#pragma once is broken". And the answer probably
is "yes, sorry, the feature is unimplementable for certain
environmental conditions".
I much prefer the current situation over the future one,
also given that the disadvantages of not having "#pragma once"
are near-zero with current #ifdef short-cutting technology.
Jens
That's does sound a lot like bullying developers with the standard in order to change their code to your preferred way of working.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jens Maurer via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, August 28, 2024 12:34:01 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jens Maurer <jens.maurer_at_[hidden]>
Subject: Re: [std-proposals] Revising #pragma once
On 28/08/2024 01.54, Arthur O'Dwyer via Std-Proposals wrote:
> (Of course it's possible that their answer is "/Nothing/ works in my environment, period; I will /never ever/ switch from #ifndef to #pragma once." In that case, the problem is solved, because we don't need to make GCC handle #pragma once in their environment — they'll never use it, so they'll never notice that it's missing.)
Not all code that wants to be compiled in a given environment
is necessarily home-grown. Maybe a third-party code provider
has decided to switch to "#pragma once" because it has been
standardized. However, now there is an expectation that it
works reliably everywhere, and we've seen good rationale it
doesn't.
We were in a situation where I could validly post a bug report
to the third-party library "your code is non-conforming; please
fix it". In the future, we are in a situation where I can't do
that anymore, and I need to post a bug report to my compiler
vendor "#pragma once is broken". And the answer probably
is "yes, sorry, the feature is unimplementable for certain
environmental conditions".
I much prefer the current situation over the future one,
also given that the disadvantages of not having "#pragma once"
are near-zero with current #ifdef short-cutting technology.
Jens
-- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-08-28 12:00:31