On 2011-06-20 15:12, Steven Schveighoffer wrote: > On Mon, 20 Jun 2011 16:45:44 -0400, Michel Fortin > > <[email protected]> wrote: > > On 2011-06-20 10:34:14 -0400, "Steven Schveighoffer" > > > > <[email protected]> said: > >> I have submitted a fix for bug 5272, > >> http://d.puremagic.com/issues/show_bug.cgi?id=5272 "Postblit not called > >> on copying due to array append" > >> > >> However, I am starting to realize that one of the major reasons for > >> > >> postblit is to match it with an equivalent dtor. > >> > >> This works well when the struct is on the stack -- the posblit for > >> > >> instance increments a reference counter, then the dtor decrements the > >> ref counter. > >> > >> But when the data is on the heap, the destructor is *not* called. So > >> > >> what happens to any ref-counted data that is on the heap? It's never > >> decremented. Currently though, it might still work, because postblit > >> isn't called when the data is on the heap! So no increment, no > >> decrement. > >> > >> I think this is an artificial "success". However, if the pull request > >> > >> I initiated is accepted, then postblit *will* be called on heap > >> allocation, for instance if you append data. This will further > >> highlight the fact that the destructor is not being called. > >> > >> So is it worth adding calls to postblit, knowing that the complement > >> > >> destructor is not going to be called? I can see in some cases where it > >> > >> would be expected, and I can see other cases where it will be > >> > >> difficult to deal with. IMO, the difficult cases are already broken > >> anyways, but it just seems like they are not. > >> > >> The other part of this puzzle that is missing is array assignment, > >> > >> for example a[] = b[] does not call postblits. I cannot fix this > >> because _d_arraycopy does not give me the typeinfo. > >> > >> Anyone else have any thoughts? I'm mixed as to whether this patch > >> > >> should be accepted without more comprehensive GC/compiler reform. I > >> feel its a step in the right direction, but that it will upset the > >> balance in a few places (particularly ref-counting). > > > > My feeling is that array appending and array assignment should be > > considered a compiler issue first and foremost. The compiler needs to be > > fixed, and once that's done the runtime will need to be updated anyway > > to match the changes in the compiler. Your proposed fix for array > > assignment is a good start for when the compiler will provide the > > necessary info to the runtime, but applying it at this time will just > > fix some cases by breaking a few others: net improvement zero. > > BTW, I now feel that your request to make a distinction between move and > copy is not required. The compiler currently calls the destructor of > temporaries, so it should also call postblit. I don't think it can make > the distinction between array appending and simply calling some other > function.
If an object is moved, neither the postblit nor the destructor should be called. The object is moved, not copied and destroyed. I believe that TDPL is very specific on that. - Jonathan M Davis
