Max Samukha wrote: > On 08/09/2010 03:40 PM, Steven Schveighoffer wrote: >> On Mon, 09 Aug 2010 08:28:38 -0400, Andrej Mitrovic >> <[email protected]> wrote: >> >>> 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." >> >> This seems totally wrong, what if an object has no default constructor? >> The spec used to say (maybe it still does) that a destructor is >> guaranteed to only ever be called once. >> >> I honestly thought the point of clear was to simply leave the memory in >> place as a kind of "zombie" object until the GC could collect it, to >> avoid having the block get recycled into a new object, and then use an >> old reference to it (via delete). I didn't know someone would ever >> purposefully use it. What is the point of calling clear then, if clear >> doesn't get rid of the object and leave it uninitialized? >> >>> But in what situation would you want to manipulate an object that was >>> already cleared and ready for garbage collection? >> >> None. That's the point. clear is saying "I don't want to use this object >> any more". The runtime (I thought) was just being conservative and >> leaving the memory in place until it could verify there were no other >> pointers to it. >> >> I'm starting to climb the fence into the "leave delete in the language" >> camp... >> >> -Steve > > I agree. The whole purpose of clearing a GC-allocated object is > deterministically freeing the resources the object may have acquired. > Otherwise, it could as well be left alive until the next garbage > collection cycle. Reconstructing the object is not a good idea since the > object may, for example, acquire an expensive resource in its > constructor etc. > > FWIW, C# solved the problem years ago by separating the destructor > (IDisposable.Dispose) from finalizer. Let's learn something from it.
IDisposable has quite a few problems and gotcha's of its own: http://www.codeproject.com/KB/dotnet/idisposable.aspx Especially these: - Finalizers are called if constructors throw an exception - Microsoft recommends that every type implementing IDisposable will check in every method and property accessor to see if it has been disposed, and throw an exception if it has
