The first approach I tried was what Thiago suggested. The second was:

// t.cpp
__COUNTER__
#include "t.hpp"

// t.hpp
#if __COUNTER__ != 0
#include __FILE__
#endif


Jeremy

On Mon, Aug 26, 2024 at 5:22 PM Arthur O'Dwyer
<arthur.j.odwyer_at_[hidden]> wrote:
>
> On Mon, Aug 26, 2024 at 3:16 PM Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Good idea. I gave that a try as well as another approach but was
>> unable to produce a sufficiently large __COUNTER__ before gcc
>> segfaulted after (around a count of 270 million). I'm impartial on
>> specifying a 32-bit counter vs a 64-bit counter, both seem reasonable
>> to me.
>
>
> Could you share your approach?
> For comparison, I used this Python script to generate 50 million __COUNTER__ invocations:
>
> cat >test.py <<EOF
> import sys
> print("""
> #define C __COUNTER__
> #define D C|C|C|C|C|C|C|C|C|C
> #define S static_assert(D|D|D|D|D|D|D|D|D|D)
> #define T S;S;S;S;S;S;S;S;S;S
> #define U T;T;T;T;T;T;T;T;T;T
> """)
> for i in range(int(sys.argv[1])):
> print("U;")
> print("")
> EOF
> time python test.py 5000 >test.cpp ; time clang++ test.cpp -fsyntax-only -std=c++17
>
> This compilation takes about 30 seconds on my machine.
> But AppleClang starts ICEing ("translation unit is too large for Clang to process: ran out of source locations") somewhere between 50 million and 100 million, so that didn't tell me anything about the practical behavior of its __COUNTER__ on overflow.
>
> FWIW, looking at the actual code of each compiler, it's easy to tell that...
> - Clang uses an `unsigned` 32-bit __COUNTER__, and wraps to zero on overflow.
> - GCC uses an `unsigned int` 32-bit __COUNTER__, and wraps to zero on overflow.
>
> Cheers,
> Arthur