Date: Mon, 26 Aug 2024 12:41:51 -0500
This was brought up by Chris Ryan in the previous email thread. This
might be interesting but as far as I can tell it's an unrelated topic.
The main use of __COUNTER__ is for unique identifiers which a
consteval function cannot help with. Unless there's interest in making
the preprocessor able to use C++ code.
Jeremy
On Mon, Aug 26, 2024 at 4:58 AM Robin Savonen Söderholm via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Just a thought before going too far here. Would it not be interesting to support the following from a meta programming perspective (which I assume the __COUNTER__ already is in some ways):
> ```cpp
> consteval int consteval_counter() noexcept {
> static int cur_count{};
> return cur_count++;
> }
> ```
>
> It can of course open up a new can of worms in regards to order of execution, but it could also potentially open up more ways for the user to customize stuff and do their own counter (or add multiple counters, if that would make any sense...)
>
> The value for "cur_count" would be independent for each translation unit, but one could also use this to create e.g. a compile-time random-number generator that could be seeded with a hash of the current file name or something like that.
>
> I am, however, not sure how difficult this would be to implement and if the benefits outweigh the costs.
>
> // Robin
>
> On Mon, Aug 26, 2024 at 11:11 AM Jens Maurer via Std-Proposals <std-proposals_at_[hidden]> 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
>>
>> > ...or have non-standard semantics.
>>
>> Improbable, given the implementation experience we've seen here.
>>
>> I'm in favor of not having a feature-test macro.
>>
>> Jens
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
might be interesting but as far as I can tell it's an unrelated topic.
The main use of __COUNTER__ is for unique identifiers which a
consteval function cannot help with. Unless there's interest in making
the preprocessor able to use C++ code.
Jeremy
On Mon, Aug 26, 2024 at 4:58 AM Robin Savonen Söderholm via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Just a thought before going too far here. Would it not be interesting to support the following from a meta programming perspective (which I assume the __COUNTER__ already is in some ways):
> ```cpp
> consteval int consteval_counter() noexcept {
> static int cur_count{};
> return cur_count++;
> }
> ```
>
> It can of course open up a new can of worms in regards to order of execution, but it could also potentially open up more ways for the user to customize stuff and do their own counter (or add multiple counters, if that would make any sense...)
>
> The value for "cur_count" would be independent for each translation unit, but one could also use this to create e.g. a compile-time random-number generator that could be seeded with a hash of the current file name or something like that.
>
> I am, however, not sure how difficult this would be to implement and if the benefits outweigh the costs.
>
> // Robin
>
> On Mon, Aug 26, 2024 at 11:11 AM Jens Maurer via Std-Proposals <std-proposals_at_[hidden]> 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
>>
>> > ...or have non-standard semantics.
>>
>> Improbable, given the implementation experience we've seen here.
>>
>> I'm in favor of not having a feature-test macro.
>>
>> Jens
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-08-26 17:42:04