Path: utzoo!mnetor!uunet!husc6!rutgers!ames!amdcad!sun!plx!dlb!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.lang.c++
Subject: null news is bad news
Message-ID: <185@goofy.megatest.UUCP>
Date: 25 Dec 87 04:59:51 GMT
Organization: Megatest Corporation, San Jose, Ca
Lines: 56



In THE BOOK, on page 93, it says, "For historical reasons, *new* simply
returns the pointer 0 when it cannot find enough store and no *_new_handler*
has been specified."

What are the historical reasons?  The history of C++ is, after all, rather
short.  That feature of C has always been a pain in the wazzoo. And
the *_new_handler* feature provides a dandy way to keep going when
core is depleted, if that's what you have to do.  You might have to
use a setjmp(), but you're up to the challenge, right?

Can anyone give me a good reason why I should not hack *new* so that
it prints an error message and terminates the program when core is
exhausted and there is no *_new_handler*?  Is there, or is there
likely to be,  code out there which DEPENDS on *new* returning 0?

Don't worry about new releases of C++. I can handle that easily enough.

I can think of one very, very good reason for *new* NOT to return 0, EVER:
library classes, A.K.A. "utilities", A.K.A. "general purpose classes".

One of the most extensively used classes at our site will be a general-
purpose hash-table package, which deletes buffers and allocates bigger
ones as necessary.  But any utility class which allocates memory will serve
as an illustration. Let's suppose I leave *new* as it is.  I have a choice:

1. I can try to inforce the convention that we put checks for NULL into
every utility which allocates memory.  And insist that any software we
purchase also do so.

2. I can try to inforce the convention that we require every utility which
allocates memory to set and then restore the *_new_handler*.

3. I can try to inforce the convention that each utility set and restore the 
new_handler if and only if it is not set already.

4. I can allow memory depletion to be handled by the SIGSEGV handler.

Each of these has a serious draw-back.  The first requires that each
utility have a convention for telling the caller when something has gone
wrong.  It clutters and complicates the code for both the utility
and the caller.

The second also clutters the code, and short-circuits any _new_handler
the caller might have set, perhaps causing the program not to behave
as intended when heap is empty.  The calling program might have set
a handler which does garbage-collection.

Number 3: Best try so far. But still error-prone.  What if somebody doesn't 
know?  Or just forgets?  At best it makes work for utility-writers.

The fourth is what would happen occasionally anyway, in practice, and is 
the stuff that all night sessions on Pepsi and twinkies are made of.

I think I've just convinced myself.  Can you show me the error of my ways?