On 07/14/2010 04:08 PM, Vladimir Panteleev wrote:
On Wed, 14 Jul 2010 22:43:00 +0300, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
You mean class objects, right? I agree. I think it's okay to fill the
object with its stateless .init members, which would assuage the issue.
Then that object may be in an invalid state, in cases when valid states
are created by the constructor.
That is correct. This is an unavoidable consequence. It doesn't have
anything to do with the existence or absence of delete. The notion of
"zombie objects" that have been disposed of any resources yet still
exist to avoid dangling pointers has been widely discussed in various
circles. D handles the matter better than all languages I know.
Also, what about classes which don't have a default constructor?
All classes have a state where all members are default initialized.
It is my understanding that you are trying to add something to the
language which would destroy an object without deallocating it (and
deprecate everything that involves on-the-spot deallocation), in order
to allow creating simpler and more efficient garbage collectors.
I'm not adding anything. I am removing a mistake that C++ made (i.e.
conflating destruction with deallocation). And the purpose is not to
assuage or help GCs. The only purpose is memory safety.
The
only correct solution seems to be to call the destructor, and mark the
object instance as invalid. The release version needn't do anything, the
debug version can stomp on the object's memory to make sure that any
code that attempts to access the object crashes quickly. (This is
practically the same as deallocation, as far as the user can see - the
difference lies in that the GC doesn't do anything immediately.)
For safety there's no debug and release. It's either safe or unsafe.
Adding a Boolean to each object to tell whether it was destroyed or not
complicates matters without bringing a palpable benefit.
Andrei
