How does the compiler know, whether it can internally do a memcpy-like optimization for trivially copyable objects? Or it (nearly) never does? Which would be a huge missed optimization opportunity for objects, which are meant for being copied in a simple way (=trivially copiable objects) - without having to read, modify and write back the last few bytes, or - if possible on the platform - without writing single bytes below the word size.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 29.11.2023 16:11 Betreff:Re: [std-proposals] void std::optional<T>::abandon(void) noexcept An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Wed, Nov 29, 2023 Lénárd Szolnoki via Std-Proposals wrote: > > The precondition for memcpy is trivially copyable *and* not potentially > overlapping. The former doesn't imply the latter. > > https://godbolt.org/z/xhsqdoz3s I've been playing around with this on GodBolt:    https://godbolt.org/z/Ecd338Go8 The output of this program on Linux x86_64 GNU g++ 13.2.0 is:    Address of b.a.i == 140727507144480    Address of b.a.ch == 140727507144484    Address of b.maybe_extra_byte == 140727507144485    77    0 So I am able to screw up the value of 'maybe_extra_byte' by memcpy'ing over the A object that exists inside B. Is this what the committee intended? If this _is_ what the compiler intended, then should every C++ compiler issue a diagnostic whenever you pass the address of a 'no_unique_address' object to memcpy? -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals