Why will the delete keyword be removed?
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Wed Jul 14 14:33:15 PDT 2010
On 07/14/2010 04:08 PM, Vladimir Panteleev wrote:
> On Wed, 14 Jul 2010 22:43:00 +0300, Andrei Alexandrescu
> <SeeWebsiteForEmail at 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
More information about the Digitalmars-d
mailing list