Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!island!grenada!roger
From: roger@grenada.UUCP (Roger Corman)
Newsgroups: comp.lang.c++
Subject: Re: Failed allocation in constructors?
Keywords: exception handling
Message-ID: <860@grenada.UUCP>
Date: 12 Jul 90 20:36:52 GMT
References: <9075@goofy.Apple.COM>
Reply-To: roger@grenada.uu.net (Roger Corman)
Organization: Island Graphics, Santa Rosa, California
Lines: 62

In article <9075@goofy.Apple.COM> escher@Apple.COM (Michael Crawford) writes:
>Can anyone suggest strategies for handling failed memory allocation
>in constructors?
>

This is the problem that has been most bothering me about C++.
Constructors and destructors are very powerful and elegant, so that
I would like to use them to hide messy memory allocations and such that
need to occur when a new object is created.  I have always felt that
good programming practice is to *always* assume that a memory
allocation can fail.  When creating commercial software packages,
especially on microcomputers, this is important.  Note that other
problems besides lack of memory can cause a constructor to fail.

How then do we test for constructor failure?

C++ provides a way of intercepting failed calls to new(), via the
'new() handler'.  This allows deallocation of unnecessary storage and other
measures to be taken when memory allocation fails.  This is a very
useful language feature, but doesn't really solve my problems.  It 
isn't useful for automatic object allocation (on the stack) because
new() isn't called.  True, new() is called by my constructor to allocate
other space for object-related things, but the problem is not at this
level.  My problem is how to handle the case when the object cannot
be allocated (for whatever reason).  The constructor needs to be able
to notify the routine which invoked it.  The other problem with the
new handler is that it is not customizable on a per class basis (I
can't have a different one for each class).

I can override new(), for each class.  I suspect that this may offer
a solution but I haven't totally thought it through.  I can live
with not being able to use automatic (stack) allocation for the classes
which allow for constructor failure.  It would be nice if I could
specify, in the object definition, that it can only be created via new()
(possible enhancement to the language?).  I typically test for 
new() returning NULL as in indicator of failure.  If I override new()
for a class, and cause it to return NULL whenever the constructor
fails, the class interface would be satisfactory.  Unfortunately,
new() does not call the constructor--the constructor calls new().
(I may be wrong on some of these points--someone please correct me.)
Even if new() did call the constructor, I would have the same problem
with the constructor not returning a value.  I could build (at least
some of) the constructor code into the new() function, but this
seems inelegant and seems to be circumventing the constructor
concept.

In some code I have written, I have added an error field to the
object which is routinely tested after an object is created, to
check for an allocation error.  This works, but seems wasteful and
messy.  Also it is easy to ignore.

I would be happy to be embarrassed by someone pointing out a trivial
way to do this which I am overlooking.  Otherwise maybe someone has
thought of a reasonably elegant way.  I have been using C++ for
about a year, and this is the only problem I have really come upon
with the language.

Roger Corman
Island Graphics
Santa Rosa, CA
{uunet,ucbcad,sun}!island!roger
(707) 523-4465