>And this "compiler can offer a option to ignore computing of ctv in
compile-time" makes absolutely no sense. Either the value is available
>at compile-time (and therefore can be used in compile-time operations)
>or it isn't. This is a property of what the code is doing, not
something that should exist as a "compiler option".
Sorry to that, it's my wrong.

获取Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Discussion <std-discussion-bounces_at_[hidden]> on behalf of Jason McKesson via Std-Discussion <std-discussion_at_[hidden]>
Sent: Sunday, July 13, 2025 11:25:57 PM
To: std-discussion_at_[hidden] <std-discussion_at_[hidden]>
Cc: Jason McKesson <jmckesson_at_gmail.com>
Subject: Re: [std-discussion] 回复: 回复: Compile-time Variables and Stateful Meta-programming / STMP

On Sun, Jul 13, 2025 at 1:29 AM SD SH via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> A compile-time variable (ctv) be declared like this:
>
> // (Assume there is a keyword called ctv)
> ctv int i = 0; // must be defined there
>
> Then compiler will allocate sizeof(int) bytes memory to storage it.
> ctv in runtime code has constinit.
>
> For safety, a ctv cannot be get the address, and cannot use compile-time new/delete.
>
> consteval int func()
> {
> return i++; // OK
> }
>
> We can get the value of it at any time, and it shows a state during compiling.
> So func() above may returns 1, 2, 3 or other value.
>
> If we need a array with unknown length, we need some new features:
>
> // ctv T&: just like a safe compile-time pointer, and we don't know where it is storaged.
> template<typename T>
> struct ctarr
> {
> public:
> template<typename... pTs>
> ctv T& allocate(pTs&&... paras); // allocate and initialize a T by T(paras...)
> // other functions, similar to other containers
> };
>
> Then using ranges to iterate it. (ctv ranges returns a ctarr)
>
> ********
>
> To compiler:
>
> In compile-time code, a ctv expresed a state,
> in runtime code, it is a normal variable.
>
> If a ctv depends is able to be use in single TU, it will be delayed (to collect all changes, similar to LTO, but it is neccessary). (It may spend more time in compiling, compiler can offer a option to ignore computing of ctv in compile-time (postpone until runtime)).

I don't know what "If a ctv depends is able to be use in single TU"
means; the phrase is garbled. If you mean "if a ctv is being used
outside of a TU", the compiler cannot know that. A compiler can only
see one TU at a time. So the compiler can assume that this is always
true or assume it is never true, but it cannot verify either
assumption.

So all ctvs will require having two-stage compilation. Every TU has to
do the regular compilation, then at link time, there has to be a
second compilation that includes all ctv usage, and then finally
there's real linking. The second compilation stage can only happen at
full link time. And since this second stage has to have the full
capabilities of C++'s compile-time operations, the compiler now needs
to effectively output compile-time executable code into object files
(since linking only gets object files).

This is very much in the "not gonna happen" territory.

And this "compiler can offer a option to ignore computing of ctv in
compile-time" makes absolutely no sense. Either the value is available
at compile-time (and therefore can be used in compile-time operations)
or it isn't. This is a property of what the code is doing, not
something that should exist as a "compiler option".
--
Std-Discussion mailing list
Std-Discussion_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion