clear()

grauzone none at example.net
Fri Oct 9 11:15:52 PDT 2009


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?

You mean for "class A1 { this() {} }", A.classinfo is not null, but for 
"class A2 {}" it is? Ask Walter to fix it by automatically inserting an 
empty constructor?

Notice that A2 doesn't define __ctor. This would also be a problem for 
manual allocation. (Although you could work around it with static 
if(is(...)).)

Actually, why don't you just check and call __ctor()? You could add a 
simple check to see if the dynamic type of the passed object is the same 
as T (in clear(T)), and raise an error if not.

What is clear() supposed to be used for anyway? I still don't understand 
why it's evil to free the memory block on delete. And now you introduce 
some clear() function, that basically destroys the object state, even 
though there still could be live pointers to it that rely on the object 
having the old state.



More information about the Digitalmars-d mailing list