Re: g++: new that throw bad_alloc ?

Re: g++: new that throw bad_alloc ?

[Joe Buck]

> I think I'd agree with the conclusion... but isn't the old-style
> behavior of new to return NULL?

The behavior of g++ 2.7.2.x is that NULL is never returned; rather,
you get a message "virtual memory exhausted" and the program exits.
It's possible to install a new_handler to get memory in some other
way.

That's why I said it's safe.

Code that wants to check the value of new needs to use the new nothrow
new (as specified in the CD2).

Re: g++: new that throw bad_alloc ?

[Joe Buck]

> Do others think we should just turn on a throwing new, and work it
> that way?

It's really risk-free to do the right thing.  The reason is that
the current default behavior is to just kill the whole program if
new fails (after any new-handlers get a chance).  Even if the throwing
new dumps core instead, that is no worse than what users have now.

Re: g++: new that throw bad_alloc ?

[Mark Mitchell]

>>>>> "Mike" == Mike Stump <mrs@wrs.com> writes:

    Mike> Do others think we should just turn on a throwing new, and
    Mike> work it that way?

I, for one, think g++ should do this.  It's going to break existing
code, I know, and it may not work at first.  But, the developers are
working hard on g++ at the moment, and on exception-handling in
particular.  Furthermore, we seem to be breaking a lot of existing
code at the moment.  At the source level, g++ just recently picked up
the new template rules for specializations, and stopped accepting
guiding declarations.  At the object level, we changed the
name-mangling scheme, and, I believe, vtable layout.  Let's
make all the breaks at once; that way users will only have to port 
their code from the old version to the new version once.  The compiler
has also been moving closer and closer to the CD2; this change would
be (another) important step in that direction.

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: g++: new that throw bad_alloc ?

[Mike Stump]

> Date: Thu, 09 Oct 1997 16:42:55 -0700
> From: Kriang Lerdsuwanakij <lerdsuwa@scf-fs.usc.edu>
> To: egcs@cygnus.com

> It would be nice to have the ability to let new throw bad_alloc

You have that ability already.  Just define a new that throws and use
it.  If this doesn't work, then that's a flaw, since that is the
intent.

> Here is my idea how it might be implemented:

> Make the default new handler check a flag when called.

I am against yet another flag.  There are far too many, and we should
look at ways of reducing them, not proliferating them.

> The default behavior is to display a message and exit for backward
> compatibility.

If we are happy with the quality and implementation of exceptions then
we can turn the default new routine into one that throws.  If the user
wants the nothrow routine, the user can call it.

I was just being conservative and wanted to be really sure that EH and
nothrow both work ok, and then later after some people with large
projects try out EH and throwing news in real code, and report back
that things work well, then change the default.

Do others think we should just turn on a throwing new, and work it
that way?

g++: new that throw bad_alloc ?

[Kriang Lerdsuwanakij]

Hi,

We have a working exception handling that is on by default, definition
of bad_alloc and new (nothrow).  It would be nice to have the ability to
let new throw bad_alloc rather than displaying the virtual memory
exhausted message.   That error should be able to be trapped by the
program.   

Here is my idea how it might be implemented:

Make the default new handler check a flag when called.  The default
behavior is to display a message and exit for backward compatibility.  
The flag can be modified by a global constructor, which is added to the
object file when some option, say, -fbad_alloc is supplied to gcc/g++.
libgcc2.a is built without the -fbad_alloc option.

I guess there is no problem with duplicate global constructors when many
files are compiled with the option.  The linker should be able to remove
them just like duplicate template instantiations.

Kriang
lerdsuwa@scf.usc.edu