I'm with Jens on this one.
If you are in the position where it could overflow, how it overflows would be the least of your problems.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Jens Maurer via Std-Proposals
Sent: Monday, August 26, 2024 12:53 PM
To: std-proposals_at_[hidden]rg
Cc: Jens Maurer <jens.maurer_at_[hidden]>
Subject: Re: [std-proposals] Second draft of a __COUNTER__ proposal



On 26/08/2024 12.38, Andrey Semashev via Std-Proposals wrote:
> On 8/26/24 12:11, Jens Maurer wrote:
>>
>>
>> On 26/08/2024 10.44, Andrey Semashev via Std-Proposals wrote:
>>> On 8/26/24 11:43, Andrey Semashev wrote:
>>>> On 8/26/24 09:33, Christof Meerwald via Std-Proposals wrote:
>>>>>
>>>>> Does this really need a separate feature test macro when you can
>>>>> just test on __COUNTER__ itself?
>>>>
>>>> __COUNTER__ may be defined by user.
>>
>> No. See [lex.name] p3.1
>
> Reserved or not, a user is not prevented from using the name. A
> compiler that does not support __COUNTER__ will not prevent the user
> from defining the macro.

Well, you get undefined behavior if you do use __anything today, unless it's a name specified by the standard. I don't think we should bend over backwards for such code.

>>> ...or have non-standard semantics.
>>
>> Improbable, given the implementation experience we've seen here.
>
> Current compilers don't implement errors on overflow, so already not
> conforming to the proposal.

My understanding is that current implementations have at least a 2^31 counter space, meaning you need 2^31 expansions of __COUNTER__ to hit the limit. That feels quite a lot, considering we're talking tokens in source code here.

Is overflow anything that happens in reality, ever?

>> I'm in favor of not having a feature-test macro.
>
> If __COUNTER__ is standardized then I'm in favor of a feature macro.

We obviously disagree here.

Jens


--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals