Date: Thu, 22 Aug 2024 17:58:41 -0700
The fact that a check like `#if defined(__COUNTER__) && (__COUNTER__ +
1 == __COUNTER__ + 0)` with fallback to __LINE__
is needed in in some libraries is evidence that standardization would
be beneficial. Furthermore, the fact that EDG does
not offer __COUNTER__ outside of microsoft mode, despite having
implemented it, is evidence counter isn't as ubiquitous
as one might expect. Certainly if it were standardized it wouldn't be
exclusive to microsoft mode.
Additionally, there is value in standardizing __COUNTER__ in the
interest of having clearly defined standard semantics.
No one should have to research a feature in half a dozen compilers to
prove to themselves that a non-standard feature
is in fact ubiquitous and portable.
Additionally, there is value in standardizing __COUNTER__ just for the
sake of having it standardized. I have
interacted with countless C++ programmers who strive to achieve a
strict pedantic compliance with the standard. I do
not personally avoid compiler extensions in my own projects simply
because they're extensions, however, I understand
why many do. It's beneficial to standardize this because it makes the
feature available to those who need strict standard
compliance. Library authors in particular could benefit from not
having to work around the absence of __COUNTER__ out
of caution. Phil also brings up a good point about feature
discoverability on cppreference and FUD about why it might
not be standard.
> nobody is prevented from using `#pragma once` just because it's non-standard
In my experience this is not the case. The primary reason #pragma once
is not more widely used is precisely because it's
non-standard and implementations might (and do) differ.
> IMO your new bullet point should go before `__DATE__`, not before `__cplusplus`.
Thanks for bringing this up. I wasn't sure whether to list it
alphabetically or put it near __DATE__, where it
makes more sense. I also appreciate the wordsmithing!
Jeremy
On Thu, Aug 22, 2024 at 8:19 AM Arthur O'Dwyer
<arthur.j.odwyer_at_[hidden]> wrote:
>
> On Thu, Aug 22, 2024 at 11:00 AM Mike Reed via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Thu, 22 Aug 2024, 16:39 Jeremy Rifkin via Std-Proposals, <std-proposals_at_[hidden]> wrote:
>>>
>>> Hello,
>>> I've drafted a proposal to standardize __COUNTER__: https://jeremy-rifkin.github.io/cpp-proposals/drafts/counter_initial_draft.html.
>
>
> > Given that nearly every use case is to produce a unique identifier, surely the last thing you want overflow to do is silently wrap to zero. I would expect the standard to mandate that overflow forces a compile error.
>
> +1 re overflow.
>
> I'm ambivalent on the proposal. It is obviously standardizing useful existing practice. But the very ubiquity of __COUNTER__ means that its standardization won't help anyone.
> One way to (politically) motivate an existing-practice proposal is to go find some implementation divergence, and claim that your proposal would resolve that divergence, thus improving the user's life. But if there is no divergence — or if your proposal fails to resolve what divergence exists — then you haven't got a case.
> An example of this scenario is `#pragma once`. Literally every vendor supports `#pragma once`; but it's never been standardized, because the cost of standardization is high and the benefit would be literally zero: nobody is prevented from using `#pragma once` just because it's non-standard.
> The cost of standardizing `__COUNTER__` is much lower (because the spec is very simple), but the benefit is still literally zero.
>
> IMO your new bullet point should go before `__DATE__`, not before `__cplusplus`.
> You might want to specify that the expansion is a decimal integer literal.
> Probably you shouldn't refer to "the value of __COUNTER__," but rather introduce a new thing e.g. "the counter" which can have a value, and then use the name __COUNTER__ only for the macro, which expands to an integer literal but doesn't have a value per se. But it doesn't make sense to spend too much time on that wordsmithing right now.
>
> HTH,
> –Arthur
1 == __COUNTER__ + 0)` with fallback to __LINE__
is needed in in some libraries is evidence that standardization would
be beneficial. Furthermore, the fact that EDG does
not offer __COUNTER__ outside of microsoft mode, despite having
implemented it, is evidence counter isn't as ubiquitous
as one might expect. Certainly if it were standardized it wouldn't be
exclusive to microsoft mode.
Additionally, there is value in standardizing __COUNTER__ in the
interest of having clearly defined standard semantics.
No one should have to research a feature in half a dozen compilers to
prove to themselves that a non-standard feature
is in fact ubiquitous and portable.
Additionally, there is value in standardizing __COUNTER__ just for the
sake of having it standardized. I have
interacted with countless C++ programmers who strive to achieve a
strict pedantic compliance with the standard. I do
not personally avoid compiler extensions in my own projects simply
because they're extensions, however, I understand
why many do. It's beneficial to standardize this because it makes the
feature available to those who need strict standard
compliance. Library authors in particular could benefit from not
having to work around the absence of __COUNTER__ out
of caution. Phil also brings up a good point about feature
discoverability on cppreference and FUD about why it might
not be standard.
> nobody is prevented from using `#pragma once` just because it's non-standard
In my experience this is not the case. The primary reason #pragma once
is not more widely used is precisely because it's
non-standard and implementations might (and do) differ.
> IMO your new bullet point should go before `__DATE__`, not before `__cplusplus`.
Thanks for bringing this up. I wasn't sure whether to list it
alphabetically or put it near __DATE__, where it
makes more sense. I also appreciate the wordsmithing!
Jeremy
On Thu, Aug 22, 2024 at 8:19 AM Arthur O'Dwyer
<arthur.j.odwyer_at_[hidden]> wrote:
>
> On Thu, Aug 22, 2024 at 11:00 AM Mike Reed via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Thu, 22 Aug 2024, 16:39 Jeremy Rifkin via Std-Proposals, <std-proposals_at_[hidden]> wrote:
>>>
>>> Hello,
>>> I've drafted a proposal to standardize __COUNTER__: https://jeremy-rifkin.github.io/cpp-proposals/drafts/counter_initial_draft.html.
>
>
> > Given that nearly every use case is to produce a unique identifier, surely the last thing you want overflow to do is silently wrap to zero. I would expect the standard to mandate that overflow forces a compile error.
>
> +1 re overflow.
>
> I'm ambivalent on the proposal. It is obviously standardizing useful existing practice. But the very ubiquity of __COUNTER__ means that its standardization won't help anyone.
> One way to (politically) motivate an existing-practice proposal is to go find some implementation divergence, and claim that your proposal would resolve that divergence, thus improving the user's life. But if there is no divergence — or if your proposal fails to resolve what divergence exists — then you haven't got a case.
> An example of this scenario is `#pragma once`. Literally every vendor supports `#pragma once`; but it's never been standardized, because the cost of standardization is high and the benefit would be literally zero: nobody is prevented from using `#pragma once` just because it's non-standard.
> The cost of standardizing `__COUNTER__` is much lower (because the spec is very simple), but the benefit is still literally zero.
>
> IMO your new bullet point should go before `__DATE__`, not before `__cplusplus`.
> You might want to specify that the expansion is a decimal integer literal.
> Probably you shouldn't refer to "the value of __COUNTER__," but rather introduce a new thing e.g. "the counter" which can have a value, and then use the name __COUNTER__ only for the macro, which expands to an integer literal but doesn't have a value per se. But it doesn't make sense to spend too much time on that wordsmithing right now.
>
> HTH,
> –Arthur
Received on 2024-08-23 00:58:45