C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Replace an object -- but retain old object if new object fails to construct

From: Jason McKesson <jmckesson_at_[hidden]>
Date: Wed, 29 Oct 2025 12:40:13 -0400
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.

Received on 2025-10-29 16:40:28