Temporary objects as function parameters or when-is-this-shit-going-to-end?

Temtaime temtaime at gmail.com
Fri Oct 13 16:49:44 UTC 2017


On Friday, 13 October 2017 at 11:21:48 UTC, Biotronic wrote:
> On Friday, 13 October 2017 at 10:35:56 UTC, Jack Applegame 
> wrote:
>> Compiler creates struct on the stack and silently (without 
>> postblitting and destruction old object) moves it to another 
>> address. Is it normal? I don't think so.
>
> It is. Structs have no identity, and the compiler/GC/whatever 
> is free to copy and/or move them about as it sees fit (as long 
> as there is ostensibly only one - no duplicate 
> constructor/destructor calls, no desynching of state). That's 
> why the documentation[1] says not to have internal pointers in 
> structs.
>
>> WAT??? Compiler creates struct on the stack copies it without 
>> postblitting and destructs both objects.
>
> Now this looks like a real bug. There should be a this(this) 
> call in there.
>
>> Can I donate to the D Foundation and that my donations would 
>> be aimed at fixing exactly these bugs?
>
> BountySource[2] lets you do basically exactly that.
>
> [1]: https://dlang.org/spec/garbage.html, "Do not have pointers 
> in a struct instance that point back to the same instance."
>
> [2]: https://www.bountysource.com/

What are the advantages of this weird behavior ?
Also if the object is finally moved then why to call ctor not on 
the moved object ?
[1] states that i cannot save the pointer inside the struct on 
the same struct(because GC can move objects in the memory, but in 
the example there's no gc as objects are on the stack), but what 
if i put &this to some global variable ? It should work as 
expected, not being partly moved. Postblit should be called as 
well as dtor of original object.

1 is a definitely a bug.



More information about the Digitalmars-d-learn mailing list