It's rather perplexing, isn't it? It states in TDPL: "After you invoke clear, the object is still alive and well, but its destructor has been called and the object is now carrying its default-constructed stated. During the next garbage collection, the destructor is called again, because the garbage collector has no idea in what state you have left the object."
But in what situation would you want to manipulate an object that was already cleared and ready for garbage collection? On Mon, Aug 9, 2010 at 2:16 PM, Steven Schveighoffer <[email protected]>wrote: > On Sun, 08 Aug 2010 23:16:48 -0400, Andrei Alexandrescu < > [email protected]> wrote: > > On 08/08/2010 01:09 PM, Andrej Mitrovic wrote: >> >>> On Page 187 it states (shortened here for convenience): >>> "By calling clear(b), you invoke b's destructor, obliterate the object's >>> state with Buffer.init, and call Buffer's default constructor" >>> >>> On the next page there's a unittest, and the entire example is this: >>> >>> import core.stdc.stdlib; >>> >>> class Buffer >>> { >>> private void* data; >>> >>> // constructor >>> this() >>> { >>> data = malloc(1024); >>> } >>> >>> // destructor >>> ~this() >>> { >>> free(data); >>> } >>> } >>> >>> unittest >>> { >>> auto b = new Buffer; >>> auto b1 = b; // extra alias for b >>> clear(b); >>> assert(b1.data is null); >>> } >>> >>> void main() { } >>> >>> The assert fails, regardless if there is another reference to the object >>> or not (b1 in this case). >>> >>> I've added some writeln()'s (not shown here), and just like the book >>> said, after clear(b), b's destructor gets called, the fields get initialized >>> to .init, and then b's constructor gets called. But the constructor will >>> allocate memory for b1.data again, which means data is not null anymore. >>> >>> So I'm guessing the assert code is wrong in the example? >>> >> >> Yes, the assert is in error. >> > > Wait wait, when destroying an object manually, the runtime will re-call the > constructor? I thought it was just going to assign the TypeInfo's initial > value to the class? > > Re-calling the constructor on destruction seems like a horrible > mis-feature. Nobody will ever use it. > > -Steve >
