Steven Schveighoffer: > The thing is, even with clear, the above code is undefined -- a cleared > object is in no state to be used. But the difference between delete and > clear is -- delete ensures the reference you delete will cause an > immediate error on use, but does nothing to prevent memory corruption to > all the other references to the same memory. Clear does the same for the > reference you clear, but also prevents memory corruption for all the other > references to the same memory. So even though you are in undefined > territory, the runtime makes a best effort to avoid you cutting off your > head. The error may still be silent, but it's not deadly.
If in nonrelease mode clear() sets a zombi-mode bit inside the object, the language can then add asserts that stop the program if a zombi object is used (field accessors too need such assert, it's an object invariant). To reduce the runtime overhead of all those asserts you can do something like C# does with the IDisposable, the language may allow to call clear() only on objects tagged with something like @clearable, so all other objects don't need those asserts. This is a fully runtime situation and I don't like it a lot. But it's not so different from what C# does. > It might even be a good idea to zero out the vtable to cause a loud error > on the next dynamic cast or virtual function call :) OK. Bye, bearophile
