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