clear()

[Jason House]

Andrei Alexandrescu Wrote:

> Andrei Alexandrescu wrote:
> > Jacob Carlborg wrote:
> >> On 10/9/09 18:40, Andrei Alexandrescu wrote:
> >>> I'm talking with Sean and Walter about taking the first step towards
> >>> eliminating delete: defining function clear() that clears the state of
> >>> an object. Let me know of what you think.
> >>>
> >>> One problem I encountered is that I can't distinguish between a default
> >>> constructor that doesn't need to exist, and one that was disabled
> >>> because of other constructors. Consider:
> >>>
> >>> class A {}
> >>> class B { this(int) {} }
> >>>
> >>> You can evaluate "new A" but not "new B". So it's legit to create
> >>> objects of type A all default-initialized. But the pointer to
> >>> constructor stored in A.classinfo is null, same as B.
> >>>
> >>> Any ideas?
> >>>
> >>>
> >>> Andrei
> >>
> >> How about this:
> >>
> >> static if (is(typeof({
> >>         auto t = new T;
> >>     })))
> > 
> > I'm in awe. Thanks, Jacob!!!
> > 
> > Andrei
> 
> Oh, wait, that doesn't work:
> 
> class A {}
> class B : A { this(int) {} }
> 
> A a = new B;
> clear(a); // oops
> 
> 
> 
> Andrei


I did not follow the whole new/delete thread, but I feel like your clear may lead to mixing too many concepts:

1. call destructor for old object
2. placement new for replacement object

In general, #1 can break code if extra references are floating around. This isn't as simple as accessing garbage memory or type safety, but also caching of data.

For single threaded code, there's two basic issues thatcan pop up:
a. Type changes
b. Placement new using global references and accidentally accessing itself.

For multithreaded code, there are race conditions where external references can be reused.


All of this is solved if you have a unique reference... Even the type issue you listed... So, what restrictions should clear impose?