And it is useful to have tools (interfaces) to write efficient code without caring whether it is 1, 2, 3, or 4.   So if I want to relocate an array of objects with a single function call, it should map or compile to a single memcpy for type 1, and also the respective most performant ones for the other types. -----Ursprüngliche Nachricht----- Von:Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 29.10.2025 17:40 Betreff:Re: [std-proposals] Replace an object -- but retain old object if new object fails to construct An:std-proposals_at_[hidden]; CC:Jason McKesson <jmckesson_at_[hidden]>; On Wed, Oct 29, 2025 at 12:06 PM Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote: > > > > On Wednesday, October 29, 2025, Arthur O'Dwyer wrote: >>> >>> >>> >>> (Type 1)  Cannot be relocated >>> (Type 2)  Can be relocated by a simple memcpy >>> (Type 3)  Can be relocated by an algorithm built into the compiler >>> (Type 4)  Can be relocated by a custom-implemented relocator algorithm provided by the author of the class >>> >> >> >> There's a very clear physical delineation between Type 1, Type 2, and "all the rest."  The line between Type 3 and Type 4 is not physical but linguistic, and arbitrary. > > > > > Key difference between a Type 3 algorithm and a Type 4 algorithm: > > Type 4 algorithm can be written in fully-portable C++ code with well-defined behaviour across all conforming implementations. An example would be the relocator for libstdc++'s std::string on Linux. (Or for any movable class: the combination of move + destroy). > > Type 3 algorithm __must__ be written in platform-specific code targeting a particular operating system, a particular CPU instruction set, or a particular software or hardware or firmware configuration. > > Type 3 will typically be written in very simple C code or assembler, whereas Type 4 will be full-blown C++ code. From the perspective of who is writing the implementation of it, that sort of thing might matter. You, a normal C++ user, cannot write a type 3 type; it will always be a type 4 type. But from the perspective of someone who is *using* such a relocatable type, this is a distinction without a difference. In both type 3 and type 4 cases, you have to call a specific interface (one that would presumably be standardized) to do relocation. From a user perspective there are only 3 cases: cannot relocate, can bit-copy-relocate, and can call the function to relocate. There must not be a usability difference between these two cases. And since it would be a standardized interface that you would override for a particular type, even the one writing the implementation doesn't really care all that much if they're relying on compiler-specific behavior or not. It's a distinction that only matters in the moment when the code is written; everything else around them doesn't care. > And more on a human note . . . you can have a very proficient C++ programmer who isn't really sure what a vtable is, and therefore doesn't even know what the Type 3 algorithm is doing, whereas any decent  C++ programmer will understand the Type 4 algorithm. Is anyone spending any real time looking at the implementation of these hyper-low-level things? Or do the vast majority of C++ users just use the tools they're given? I agree with Arthur that the distinction is not practically relevant to the standard functionality. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals