Path: utzoo!mnetor!uunet!husc6!think!ames!fxgrp!ljz
From: ljz@fxgrp.UUCP (Lloyd Zusman, Master Byte Software)
Newsgroups: comp.lang.c++
Subject: Re: null news is bad news
Message-ID: <191@fxgrp.UUCP>
Date: 27 Dec 87 20:18:26 GMT
References: <185@goofy.megatest.UUCP>
Reply-To: fxgrp!ljz@ames.arpa (Lloyd Zusman, Master Byte Software)
Followup-To: <185@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones)
Organization: FX Development Group, Inc., Mountain View, CA
Lines: 71

In article <185@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
>
>
>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."
> ...
>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?
> ...

Please, please, please ... I beg of you, PLEASE don't do that.

I used a C compiler under MSDOS a few years ago that did the same thing
when malloc() failed:  it printed a message and caused the program
to exit.  We were developing a screen-oriented software package.  When
our customers would run the code with a lot of the IBM PC's memory
taken up with resident code, malloc() would fail often.  Since we were
using the PC's BIOS system to manipulate the screen, and since the
message was written to stderr (or stdout ... I forget), the message
would come out either behind a window, where it couldn't be seen,
or in big, wierd-looking letters in some random location in the middle
of the screen.  In either case, the system would have to be reset to
some known, "nice" state before anything meaningful could be read
from the screen.

We finally changed to a different C compiler whose malloc() worked in
the conventional manner.  This allowed us to check its return value
and cause a very graceful exit if the system ran out of memory.  We
would clear the windows and print out a nice message telling the user
that too much resident memory has been taken up on his or her system,
and that our software won't run properly unless some of it is removed.
Then, the program would exit and leave the screen in a normal, usable
state.  This kind of control over the user interface is extrememly
important when selling software.  People don't like to buy software
that exits unexpectedly with the machine in a state that requires a
reset procedure before anything else can run.  People will call and
ask for their money back.  You need to control the system at all times
to avoid these "messy" states.  Remember, C++ runs on machines other
than unix boxes.  For example, there are at least two implementations
of it on the IBM PC, where there is no signal handling for things like
SIGSEGV, where memory is at a premium and malloc() [ or 'new' ]
failures happen as a matter of course, and where an "ungraceful" exit
from a program could cause the user to have to reboot the machine.

In C++, the programmer could use _new_handler to deal with this kind
of problem, but it has a serious drawback: within the _new_handler
routine you don't know which 'new' had failed.  There are usually
several calls to 'new' in a program.  Many times, the failure of one
'new' has a different impact on the system than the failure of
another.  Sometimes I'd like to know exactly which 'new' has failed
and take whatever action is appropriate at that time.  Hence, sometimes
I don't want to use _new_handler so I can check if a specific 'new'
has returned a NULL and react accordingly.

Perhaps what you could do is provide some sort of default _new_handler
that prints a message and exits, but which could be overridden by the
programmer setting _new_handler to NULL, in which case 'new' would
behave the way it is defined to behave in "the book".  But whatever
you do, *please* don't protect me from myself.  If your C++
implementation is ever for sale, I would not buy it if its 'new'
behaved the way you suggested in your posting.


-------------------------------------------------------------------------
 Lloyd Zusman
 Master Byte Software
 Los Gatos, California	    	    	Internet:   fxgrp!ljz@ames.arpa
 "We take things well in hand."	    	UUCP:	    ...!ames!fxgrp!ljz