NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/cplus/12757

Internet Message Format | 1992-08-21 | 3.5 KB

Path: sparky!uunet!timbuk.cray.com!equalizer!sdcrsi!network.ucsd.edu!swrinde!mips!darwin.sura.net!jvnc.net!yale.edu!nigel.msen.com!hela.iti.org!cs.widener.edu!phlpa!cs.widener.edu!dsinc!ub!zaphod.mps.ohio-state.edu!cs.utexas.edu!wupost!uunet!centerline!matt
From: [e-mail] (Matt Landau)
Newsgroups: comp.lang.c++
Subject: Re: Return value for the constructors.
Message-ID: <[e-mail]>
Date: 20 Aug 92 17:38:35 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Distribution: usa
Organization: CenterLine Software, Inc.
Lines: 56
Nntp-Posting-Host: rapier

In <[e-mail]> [e-mail] (Paul Lucas) writes:
>In <[e-mail]> [e-mail] (Matt Landau) writes:
>>In <[e-mail]> [e-mail] (Ramon Pantine writes:
>>>>>Sure there is: Overload operator new()...
>>>>
>>>>*****>    Clever...but it's not reentrant.

>>>Paul, that is a moot point given that the object might not always be
>>>created thru new ...

>>Of course it's fairly straightforward to FORCE all objects of a given
>>class to be created via the class operator new ...

>*****>    And this is supposed to be clean and simple??  Anyway, not
>    allowing auto objects to too high a price to pay.

No, I never said it was clean and simple, just that it was possible.

In fact, I think it's a bad idea in most cases, although without a widely
available implementation of exception handling, most of the alternatives
for handling constructor failure are also pretty gross.

My own style has evolved to one in which I try very hard to write ctors
that CANNOT fail, and put failure-prone operatations into a secondary
initialization member function that's called after construction.  (I'm well
aware that this technique also makes it difficult or impossible to write
certain kinds of classes; for those, we just use a different kludge :-)

This is ungraceful, and the kind of thing that ctors were supposed to
avoid in the first place by ensuring that an object will be initialized
before it can be used, but the pragmatics seem to be that without any
exception handling, ctors fall short of the goal.

>>Arrays are still a problem...

>>Presumably this limitation would go away if X3J16 actually designed an
>>operator new[] and someone actually implemented it :-)

>*****>    Or better, when exception-handling gets here.

Yes, but from all recent accounts, it sounds like it will be at least
a year before an ANSI standard exception handling extension is approved
and implemented in enough C++ compilers to make it worthwhile.  Not that
operator new[] is likely to be approved and widely implemented in less
than a year, either.

The point is just that implementation all of these "good" mechanisms for
handling the more egregious shortcomings in C++ are a long way off, and
there's an awful lot of code being written in the meantime for which
SOME error avoidance or handling conventions and idioms would be useful.

[Also, having worked on a large software system that used exceptions as
a primary means of error reporting and recovery, I'm not convinced that
it's the panacea some people seem to think it will be.  Dealing with
exceptions correctly in large systems rapidly becomes tedious and error
prone itself.]