On 30/04/2021 18:07, Tom Honermann via Std-Discussion wrote:
> On 4/30/21 10:16 AM, Hyman Rosen via Std-Discussion wrote:
>> This is where the conceptual error of the C++ object model shows. A pointer or reference points to memory, not to an object. The pointer type informs how that memory should be treated. If the memory remains allocated to the program, the pointer is valid. If the contents of the memory are valid for a type, the object of that type in that memory is valid.
>
> I tried to point this out elsewhere in this thread, but I'm not sure the point landed.
>
> If the C++ object model worked as you state it should, then constexpr evaluation would not be feasible or would be more constrained than it currently is. With a memory based model, the implementation would have to mimic memory layout for the target architecture in order for code to behave the same at compile-time vs run-time. The C++ object model avoids that by allowing the implementation to represent objects differently during constant evaluation, but in a way that isn't observable.

Given the following program:

union U {
 struct S1 { int i; int j; } s1;
 struct S2 { char c[8]; } s2;
} u;

static_assert((void*)&u.s1.j == (void*)&u.s2.c[4]);

and the fact that run-time assert with the same condition would not fail, how should static_assert «behave»?

1) It is not allowed to fail
2) It is allowed to fail
3) The condition is not a constant expression

If 1), how is it possible without mimicking memory layout?
If 2), how does it agree with the fact that code must behave the same at compile-time vs run-time?
If 3), why?