www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Arrays and struct assignment, pt. 2

reply "David Nadlinger" <code klickverbot.at> writes:
Here is another example where neither opAssign nor the dtor are 
called for an assignment (unless a postblit is added too):

---
uint dtorCount;

struct S {
   uint x;
   void opAssign(const ref S rhs) { assert(false, "Not called"); }
   ~this() { ++dtorCount; }
}

void main() {
   S[] a;
   a.length = 1;
   a[0].x = 42; // Some random non-init value

   a[] = S.init;

   assert(a[0].x == 0); // As expected, the value has been reset
   assert(dtorCount == 0); // Passes?!?
}
---


Again, am I missing something obvious here? I can't quite believe 
that struct lifetime would have been quite as broken for so long.

  – David
Aug 01 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Sunday, 2 August 2015 at 01:50:50 UTC, David Nadlinger wrote:

 Again, am I missing something obvious here? I can't quite 
 believe that struct lifetime would have been quite as broken 
 for so long.


I suspect that what it comes down to is that opAssign doesn't get 
used all that frequently. Most structs simply don't need it, so 
code which would hit the bug probably isn't all that common. 
Obviously, such code exists, but it requires using both opAssign 
and then putting those structs in arrays - and then catching the 
resulting bug (which you would hope would happen, but if the 
difference is subtle enough, it wouldn't necessarily be caught). 
And if structs with opAssign normally also define a postblit, 
then it's that much less likely that the problem would be hit.

- Jonathan M Davis
Aug 01 2015
parent reply "Etienne Cimon" <etcimon gmail.com> writes:
On Sunday, 2 August 2015 at 02:49:03 UTC, Jonathan M Davis wrote:

 On Sunday, 2 August 2015 at 01:50:50 UTC, David Nadlinger wrote:

 Again, am I missing something obvious here? I can't quite 
 believe that struct lifetime would have been quite as broken 
 for so long.


 I suspect that what it comes down to is that opAssign doesn't 
 get used all that frequently. Most structs simply don't need 
 it, so code which would hit the bug probably isn't all that 
 common. Obviously, such code exists, but it requires using both 
 opAssign and then putting those structs in arrays - and then 
 catching the resulting bug (which you would hope would happen, 
 but if the difference is subtle enough, it wouldn't necessarily 
 be caught). And if structs with opAssign normally also define a 
 postblit, then it's that much less likely that the problem 
 would be hit.

 - Jonathan M Davis


I couldn't get reference counted types to work as struct members, 
for some hard-to-track reason, and am actively avoiding it right 
now as a result. Maybe we've found a cause here? The might be a 
lot of people like me that gave up trying to track it, and are 
simply avoiding error-prone uses of structs.
Aug 01 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Sunday, 2 August 2015 at 03:18:59 UTC, Etienne Cimon wrote:

 On Sunday, 2 August 2015 at 02:49:03 UTC, Jonathan M Davis 
 wrote:

 On Sunday, 2 August 2015 at 01:50:50 UTC, David Nadlinger 
 wrote:

 Again, am I missing something obvious here? I can't quite 
 believe that struct lifetime would have been quite as broken 
 for so long.


 I suspect that what it comes down to is that opAssign doesn't 
 get used all that frequently. Most structs simply don't need 
 it, so code which would hit the bug probably isn't all that 
 common. Obviously, such code exists, but it requires using 
 both opAssign and then putting those structs in arrays - and 
 then catching the resulting bug (which you would hope would 
 happen, but if the difference is subtle enough, it wouldn't 
 necessarily be caught). And if structs with opAssign normally 
 also define a postblit, then it's that much less likely that 
 the problem would be hit.

 - Jonathan M Davis


 I couldn't get reference counted types to work as struct 
 members, for some hard-to-track reason, and am actively 
 avoiding it right now as a result. Maybe we've found a cause 
 here? The might be a lot of people like me that gave up trying 
 to track it, and are simply avoiding error-prone uses of 
 structs.


Well, another thing to consider is that until very recently, 
structs that were on the heap didn't have their destructors run. 
So, there have been way too many holes with regards to this sort 
of thing and structs. I don't know how many people have stayed 
away from using structs in error-prone cases like this as opposed 
to simply had buggy code and not noticed it, but there very well 
may be quite a few folks out there who have hit this sort of 
thing and then been very confused about the subtle bugs that 
resulted, and it's just that no one who noticed figured it out 
well enough to report it.

- Jonathan M Davis
Aug 01 2015
prev sibling parent Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-08-02 10:50 GMT+09:00 David Nadlinger via Digitalmars-d <
digitalmars-d puremagic.com>:


 Again, am I missing something obvious here? I can't quite believe that
 struct lifetime would have been quite as broken for so long.



https://issues.dlang.org/show_bug.cgi?id=14860
https://github.com/D-Programming-Language/dmd/pull/4856

Kenji Hara
Aug 01 2015