Date: Fri, 30 Apr 2021 18:14:01 +0300
On Fri, 30 Apr 2021 at 18:09, Tom Honermann via Std-Discussion
<std-discussion_at_[hidden]> 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. This does put some constraints on what operations can be performed at compile-time (e.g., no reinterpret_cast), but allows a clear subset of the language to be used in both evaluation contexts.
>
> Just to make that a little more concrete, here is an example that mimics a vector insert operation (including use of placement new as would be done by std::allocator). All major compilers reject the example. If constexpr is removed from the declaration of f()::v, some compilers still reject it (I assume the ones that accept it do so as a conforming extension, but I'm not sure). For those that accept it, they do (currently) behave as you describe; the dereference of the pointer yields the value of the replacement object, including under optimization.
Gee. It's almost as if you're suggesting that the memory model and the
object model are used for symbolically
computing various kinds of correctness proofs.
<std-discussion_at_[hidden]> 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. This does put some constraints on what operations can be performed at compile-time (e.g., no reinterpret_cast), but allows a clear subset of the language to be used in both evaluation contexts.
>
> Just to make that a little more concrete, here is an example that mimics a vector insert operation (including use of placement new as would be done by std::allocator). All major compilers reject the example. If constexpr is removed from the declaration of f()::v, some compilers still reject it (I assume the ones that accept it do so as a conforming extension, but I'm not sure). For those that accept it, they do (currently) behave as you describe; the dereference of the pointer yields the value of the replacement object, including under optimization.
Gee. It's almost as if you're suggesting that the memory model and the
object model are used for symbolically
computing various kinds of correctness proofs.
Received on 2021-04-30 10:14:14