On 2010-08-09 20:53:16 -0400, Andrei Alexandrescu
<[email protected]> 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
[email protected]
http://michelf.com/
