On Wed, Oct 29, 2025 at 12:50 PM Sebastian Wittmeier via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.

Note that "type 1" represents types that can't be relocated at all. So
such code should fail to compile. But yes, the same interface that's
used to relocate type 3&4 should also be performance-friendly for type
2 cases. The only time you need to care about type 2 as a distinct
possibility is if you're relying on low-level bit fiddling.

And that's a non-trivial set of cases. If you want to be able to
serialize objects via their binary data (or use memory mapped IO to do
something similar), you need to be able to separate type 2 types from
the rest. But if you want such serialization to handle type 3, then
there's no reason it couldn't handle type 4 either (since regardless
of how it gets implemented, the interface would be the same).

> -----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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals