Thread overview
Assigning &this in constructor.
Jan 18, 2017
NotSpooky
Jan 18, 2017
Adam D. Ruppe
Jan 18, 2017
pineapple
Jan 19, 2017
NotSpooky
Jan 19, 2017
Adam D. Ruppe
January 18, 2017
Is it undefined behavior to assign &this to a pointer in the constructor of a struct?
January 18, 2017
On Wednesday, 18 January 2017 at 22:57:22 UTC, NotSpooky wrote:
> Is it undefined behavior to assign &this to a pointer in the constructor of a struct?

Yes:

http://dlang.org/spec/struct.html
"A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient."

That means it might copy and/or move it without giving you a chance to update the pointer. Updating in postblit can help sometimes but still the compiler and library are allowed to move structs without notice.
January 18, 2017
On Wednesday, 18 January 2017 at 23:08:07 UTC, Adam D. Ruppe wrote:
> On Wednesday, 18 January 2017 at 22:57:22 UTC, NotSpooky wrote:
>> Is it undefined behavior to assign &this to a pointer in the constructor of a struct?
>
> Yes:
>
> http://dlang.org/spec/struct.html
> "A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient."
>
> That means it might copy and/or move it without giving you a chance to update the pointer. Updating in postblit can help sometimes but still the compiler and library are allowed to move structs without notice.

Practically speaking I've found that if the struct was allocated on the heap, then &this acquires that pointer and seems not to break anything, e.g. how it's used in the uncopyable struct here https://github.com/pineapplemachine/mach.d/blob/master/mach/collect/linkedlist.d#L165
January 19, 2017
On Wednesday, 18 January 2017 at 23:08:07 UTC, Adam D. Ruppe wrote:
> On Wednesday, 18 January 2017 at 22:57:22 UTC, NotSpooky wrote:
>> Is it undefined behavior to assign &this to a pointer in the constructor of a struct?
>
> Yes:
>
> http://dlang.org/spec/struct.html
> "A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient."
>
> That means it might copy and/or move it without giving you a chance to update the pointer. Updating in postblit can help sometimes but still the compiler and library are allowed to move structs without notice.

You already answered on the IRC so thanks X2.
So, it's problematic to have pointers to structs in all cases according to spec?
January 19, 2017
On Thursday, 19 January 2017 at 00:55:42 UTC, NotSpooky wrote:
> You already answered on the IRC so thanks X2.
> So, it's problematic to have pointers to structs in all cases according to spec?

Maybe... though in practice (and with C compatibility), pointers to ones where you know the memory management scheme is fine.

So if you declare a local, and get a pointer to it, you're OK. Or if you new it, or malloc it, or something like that.

The big problem with a pointer to itself in the constructor or as a member is that the struct itself doesn't know where it is going or how it was allocated, just the code outside does.