DIP 1014

[Timothee Cour]

@Manu, @Jonathan M Davis

> GNU's std::string implementation stores an interior pointer! >_<

it's not just GNU's std::string ; it can crop up in other places, see
https://github.com/Syniurge/Calypso/issues/70 in opencv (cv:: MatStep)


On Wed, Oct 3, 2018 at 8:10 PM Shachar Shemesh via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 03/10/18 23:25, Stanislav Blinov wrote:
> > It *is* true when the type doesn't have a destructor. Extending that to
> > a move hook, it will also be true because destruction will be elided.
> > I know what you're talking about, that happens for types that have
> > destructors.
>
> No, destructors have nothing to do with it, as well they shouldn't. The
> whole point of D moving structs around is that no destruction is needed.
> It took me a while to figure out why your program does appear to work.
> At first I thought it was because of inlining, but that was wrong.
>
> The reason your test case works (sometimes, if you don't breath on it
> too heavily) is because the object is actually moved twice. Once when
> returning from the function into the variable, and another when copied
> into opAssign's argument. This results in it returning to its original
> address.
>
> If you do *anything* to that program, and that includes even changing
> its compilation flags (try enabling inlining), it will stop working.
>
> You should have known that when you found out it doesn't work on ldc:
> ldc and dmd use the same front-end. If you think something works
> fundamentally different between the two, you are probably wrong.
>
> To verify my guess is right, I tried the following change: add to
> createCounter and createCounterNoNRV in your original program (no
> destructors) the following two lines:
>    int a;
>    write(a);
>
> You have added another local variable to the functions, but otherwise
> changed absolutely nothing. You will notice your program now has an offset.
>
> Shachar