Re: doubt related to 'new' in MFC
On Thu, 5 Jul 2007 10:42:13 -0700, "David Ching"
<dc@remove-this.dcsoft.com> wrote:
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:pa6q83daglle64295srne9bjsudbeglts6@4ax.com...
If you are using delete, you're probably writing code that is not
exception-safe. Use smart pointers instead.
Would you further explain this? How is using delete not exception safe? Is
it simply because the code which calls delete may not be executed if there
is an exception? Would moving such code to the finally block fix this?
It's not obvious to me how smart pointers are any better at this, other than
the dtor is always called, but the the delete call would always as well, if
it were in a finally block.
C++ doesn't have "finally". I was thinking about this:
int* p = new int;
.... code that can throw exceptions
delete p;
You can make this exception-safe like this:
int* p = new int;
try
{
... code that can throw exceptions
}
catch (...)
{
delete p;
throw;
}
delete p;
But that's clumsy and not using C++ EH effectively. What you ought to write
is something like this:
std::auto_ptr<int> p(new int);
Now the object will be deleted no matter how the smart pointer goes out of
scope, whether it be falling off the end of its block, early return, or via
exception. Even if C++ had "finally", the RAII technique is still more
elegant in that you don't have to write the try/finally blocks.
The reason I religiously delete all data members that I new is because I
don't want to assume how my class is going to be used, and what it's
expected lifetime is. This is different than perhaps what you are talking
about, but in these days of rampant copy/paste, your code that merely
instantiates a global var for the lifetime of an app could easily be copied
into a method of an object whose lifetime is more transient.
I did say with regard to destroying objects even when strictly unnecessary
that "I do recommend you do it anyway", and what you're talking about is
essentially my point (3), that you tend to find yourself with code you have
to "unoptimize" at some point. Trying to micromanage this is rarely worth
the trouble, as gains are minimal for most apps and the potential for error
is high. Other arguments against I described include spurious leak reports
and that it is often harder not to do it than it is to do it. In case it
isn't clear, I'm saying you would need an exceedingly good reason to rely
on the OS to reclaim resources used by objects that live until the program
terminates, rather than to do it yourself.
--
Doug Harrison
Visual C++ MVP