🚀 go-pugleaf

In article <199604121609.MAA27937@jabba.lehman.com> ajay@lehman.com
(Ajay Kamdar) writes:

|> 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.

Well, I agree fully that it is bad programming practice to let
exceptions propagate out of a destructor.  At present, however, it is
legal C++ (although if the committee were to declare it undefined
behavior, they wouldn't get any objections from me), and as such, should
be taken into consideration when designing a *standard* library
component.  (I *don't* take it into consideration when designing my own
components.  But: if you don't like my style, you aren't obliged to use
my components.  Everyone has to use the standard components, however.)

|>                 [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
                  ^^^^^^^^^^^^^^^^^^

Would that it were.  But if this were really true (for portable
programs), then we wouldn't have to argue the point about auto_ptr,
would we?  There'd be no need of the class in any of its forms.  (I'll
trade you namespaces, RTTI and exceptions for garbage collection.)

|> 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.

I'm not going to reiterate my arguments, since I really have nothing to
add.  I understand your position, and in fact largely agree with the
points you have made.  I just feel that there are other issues involved
which are more important.  (I also feel that the only real solution is
garbage collection, which allows the semantics I want with the safety
you want.  Maybe if commercial providers will start implementing
something like the Boehm collector as an extension, we will have the
existing practice necessary to get it into the next revision.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]