TDPL: Manual invocation of destructor

Michel Fortin michel.fortin at michelf.com
Mon Aug 9 18:14:18 PDT 2010


On 2010-08-09 20:53:16 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Jonathan M Davis wrote:
>> I would take that as an argument for making clear() set the object in 
>> the state prior to the constructor call.
> [snip]
> 
> I agree. Do others?

Well, allowing clear on any class is dangerous for a program's 
integrity as a whole, whether you call a destructor or not.

So my opinion is that it should either not exist, if it exists it 
should be buried somewhere with other functions that subvert the type 
system, and if it's not buried enough there should be a way to disable 
it for certain classes. That last option is quite like disabling the 
copy constructor in C++; I'd much prefer an opt-in than an opt-out 
option.

Beyond that I could not care less whether it does one or the other. In 
fact, why not create two variants of the function? There are valid use 
cases for both behaviours in my opinion.

	destroy(); // call destructor and wipe memory to init state
	reconstruct(); // call destroy() then call constructor

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list