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_at_[hidden]> on behalf of Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, August 22, 2024 5:35:59 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Andrey Semashev <andrey.semashev_at_[hidden]>
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_at_[hidden]> 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_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals