That could be solved if you could reset the counter to some value. Or better yet the ability to have more than one counter.
Or perhaps one could dream of a pre-processor language, after all incrementing a counter is just a small subset of things you would want to do with a macro.
From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Thursday, August 22, 2024 5:35:59 PM
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Andrey Semashev <andrey.semashev@gmail.com>
Subject: Re: [std-proposals] __COUNTER__
 
On 8/22/24 18:22, René Ferdinand Rivera Morell via Std-Proposals wrote:
> On Thu, Aug 22, 2024 at 10:00 AM Mike Reed via Std-Proposals
> <std-proposals@lists.isocpp.org> wrote:
>>
>> 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.
>
> Given that.. It would be more useful to standardize some form of
> __UUID__ that matches the current __COUNTER__ use cases.

I think, it would make ODR issues even worse than __COUNTER__. Imagine
__UUID__ used in a header included in multiple TUs.

You could argue for some sort of hash over __FILE__ and byte offset in
the current file combined, where __FILE__ is a canonical path.

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals