🚀 go-pugleaf

In article <KANZE.96Apr10111407@gabi.gabi-soft.fr>,
J. Kanze <kanze@gabi-soft.fr> wrote:
>In article <4kcr2d$p03@jabba.lehman.com> ajay@lehman.com (Ajay Kamdar)
>writes:
>
>|> You didn't say whether the example I gave was exception
>|> safe or not.
>
>But I did.  It's not.
>
>|> To reiterate the main points of the example
>|>    + The caller directly initializes an auto_ptr with
>|>      the returned value from the calee.
>|> 	 auto_ptr<X> ptr(get_X());
>
>|>    + The callee releases the pointer from it's own
>|>      auto_ptr in it's return statement.
>
>|> No copy constructors are involved in the return. Hence
>|> there is no possibility of an exception thrown from
>|> a user defined copy constructor. So which window are
>|> you referring to during which there is no exception
>|> safety? I claim there is none.
>
>The destructors of any local variables in get_X.

Yes, you are right that the destructors of local variables in
get_X() could propagate exceptions. I missed that in my initial
analysis. However, in a previous article I believe I have shown
clearly that propagating exceptions out of destructors is an
extremely poor practice. Depending upon whether the destruction
of remaining stack variables in get_X() is attempted if one of
the statck variables throws an exception, the program will either
terminate or will likely leak memory. I think it would be a
dubious choice to make auto_ptr less safe to use by making it have
copy semantics to support such off beat no-win cases.



                [snip]
>
>|> So which one is better for the C++ programmer? An approach
>|> which can lead to disastorous surprises at run-time
>|> (auto_ptr with copy semantics approach) definitely does
>|> not look the right choice under any stretch of imagination.
>
>In short, you are suggesting that memory leaks are OK, as long as they
>don't occur too often.  This isn't the case for my applications.


Applications which cannot tolerate even occasional memory leaks
when exceptions propagate through destructors (if they are
lucky to live past those exceptions) should go through sufficient
testing to find all such occurences. Enough memory leak detection
tools exist on the market to make this possible. The onus
of finding those leaks is on those applications. Alternatively
they could use garbage collection. Given that even an auto_ptr
having copy semantics does not really solve the problem with
exceptions emnating from destructors, I have a hard time buying
into warping the auto_ptr design and making it unsafe for
everyone to support such applications.

Moreover, if the unsafe copy semantics are moved out of auto_ptr
into taligent_ptr, applications which are willing to accept
the unsafe semantics and the lack of a complete solution inspite
of sacrificing safety can always use the taligent_ptr. But it
would be a *choice* that is not imposed upon everyone using the
standard auto_ptr class.

--
Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer 
Lehman Brothers    |    Phone: (201) 524-5048     |
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]