Date: Mon, 26 Aug 2024 11:58:04 +0200
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
>
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
>
Received on 2024-08-26 09:58:24