On Friday 23 August 2024 01:33:31 GMT-7 Andrey Semashev via Std-Proposals
wrote:
> > I'm weary of feature-creeping this paper; my goal is to standardize
> > existing practices rather than introduce new
> > features. It might be worth considering this for a follow-on paper.
> > Even if some sort of __UUID__ were provided, it
> > would still be beneficial to standardize __COUNTER__ given its widespread
> > use.
> Existing practice may not be the thing to standardize if there is a
> significant drawback to it. ODR issues related to __COUNTER__ are such a
> drawback, and I don't think you can solve it without dropping the
> concept of a counter altogether.

Existing practice is that __COUNTER__ can't be used anywhere where ODR is
expected, because it may change for the other TU that included this header. I
don't see a problem standardising it with its current behaviour and no ability
to reset it. In fact, I would oppose any attempt to allow resetting the
counter, because that would in turn allow breaking code using __COUNTER__ that
currently does work just fine.

But as Jens said, that doesn't mean __COUNTER__ is the best solution. Maybe
what we do need is a file-local identifier based on the file's name, such that
it's always the same whatever the #include chain was to reach that file, but
unique within it. It probably needs to keep incrementing if the file is
#include'd again, like <assert.h> is. That may solve both problems: the need
for unique identifiers that won't collide with whatever else is defined by the
same macro in other places in the TU, but the same identifier in all TUs.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering