Re: ~ destructor doesn't destroy object?
On Dec 10, 3:03 pm, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
When object is on stack, or embedded in (a member of) another object,
I know of no practical reason to call destructor explicitly.
Because you want to use placement new to reset the object to its default
state? Yes, unusual but not inconceivable. That is why the Standard
explicitly allows such as long as the destroyed object is replaced by an
object of the same type before the automatic dtor call.
If that's the case, I'd rather do:
{
TYPE object1(params);
// workworkwork
}
{
TYPE object2(params);
// workworkwork
}
If compiler can reuse object1's stack for object2, I get all for free
without abominations. If not, and if stack space is a problem, I'd
just go on the heap.
Note that using blocks is also more exception safe, too, e.g.:
TYPE object(params);
// workworkwork
object.~TYPE();
try
{
pObject = new (&object) TYPE(params)
}
catch(blah) {}
object.crash_here();
If there are other references to said object, and it has to go to
initial state I'd prefer e.g. a "clear" method. In fact, if there are
said references, situation is even worse WRT exception safety: if ctor
throws, object isn't constructed anymore (a MAJOR nono), and yet,
there are references to it. And if base class, or some member ctor
throws, in usual implementations, virtual table stays broken, which is
__utter__ disaster.
So to me, your use clearly falls under "just because you can, doesn't
mean you should".
Goran.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]