On 1/26/24 15:39, Jan Schultke wrote:
>> Upon loading the executable, the representation of the object is also mapped into the process address space, so really no initialization happens at run time ...
>
> So ... loading the executable and mapping the object representation of
> the object happens at compile-time, not at run-time? This is obviously
> false.

As far as the C++ standard is concerned, it is. More precisely, it
happens before dynamic initialization and running main(), i.e. before
any of the program's code runs.

> I get that it's cheap, and on modern architectures, doesn't require
> any work to be done individually per object, but let's not get
> sidetracked by implementation details. As described in
> https://eel.is/c++draft/basic.start.static, all static initialization
> strongly happens before dynamic initialization. However, it doesn't
> happen "at compile-time". This would imply that the lifetime of the
> object has begun before you have turned on your PC, let alone run the
> program.

An object initialized during constant initialization stage is
initialized before any of the program code runs and exists through the
whole time of the program execution, including the program termination.
So, as far as the standard is concerned, the object could as well exist
eternally.

>> A variable declared constexpr specifies to create a compile-time constant which can be used in other constant expressions.
>
> No. It specifies that (https://eel.is/c++draft/dcl.constexpr#6)
>> the full-expression of the initialization shall be a constant expression

You're quoting one requirement for a declaration to be a valid constexpr
object declaration. I'm saying what constexpr means and why it was
introduced in the first place.

> In practice, this makes it feasible for implementations to evaluate
> the initializer prior to program startup; however, this is not
> required and wouldn't be implementable when writing a C++ interpreter.

Exactly.

> However, I think it's reasonable to slightly
> misuse the constinit keyword to equally imply that "the
> full-expression of the initialization shall be a constant expression",
> however, without also implying const.

I disagree. I don't think that diluting the meaning of constinit is a
good idea, especially given that C++ is already confusing as it is in
this area. We now have three similar keywords, all working in the same
area but to slightly different aspects and intentions. Let's not make it
worse by making these aspects less well defined.