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?
