In article <2hd1vf$scf@wcap.centerline.com> matt@centerline.com (Matt Landau) writes:
>In <CJnqsD.Az1@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>>If either the allocation or constructor fail, an exception will
>>be thrown. ...
>>
>>It does, however, require a completely new way of thinking:
>
>It also breaks pretty much every existing nontrivial C++ program.  Any
>program that currently checks for NULL returns from new and handles memory
>allocation errors (and there are plenty of programs that do) is silently
>broken by this change.  Runtime allocation errors that were previously
>handled by the program now generate uncaught exceptions, resulting in
>calls to unexpected(), and -- by default, at least -- program termination.
>
>What's worse is that the fix is nontrivial; every existing program must
>add a whole new layer (and style) of control flow, wrapping code in try
>blocks.  There is no automatic or mechanical process that can accomodate
>this langauge change -- it must be done by hand, by analyzing and then
>potentially restructuring the code.

 Yes, more or less I think you are correct.
>
>What's even worse is that if you REALLY want this behavior, you can
>get it right now, WITHOUT a language change.  Just write a new_handler
>that throws xalloc for you.

 Not quite. This wont properly deallocate the memory.
Unless the compiler has been written to expect exceptions thrown
from new handlers.

>I fail to see why a language change with
>such sweeping implications is required.

 Because its theoretically sound, and the correct
way to do things. Big changes happened to C++ before.
After Standardisation, you can expect clarifications and
additions, and upward compatibility, unless specifically
advised a feature is deprecated.

>And this came from the same committee that added a wart like ++ on
>boolean types to avoid breaking existing code, even though such code
>is of dubious design and could be fixed almost mechanically?

>Something just doesn't add up ...

 Breaking existing code is considered worth it sometimes,
if there are major gains, as there are in this case. Another
example is "mutable". You cant write to const objects now,
and that also requires work upgrading your code where you
previously cast away const legally.

 PS: most implementors allow you to say
"set_new_handler(0)" to enable the old behaviour.
So, your code is "broken" but in practice, it will still work.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In <CJnqsD.Az1@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>If either the allocation or constructor fail, an exception will
>be thrown. ...
>
>It does, however, require a completely new way of thinking:

It also breaks pretty much every existing nontrivial C++ program.  Any
program that currently checks for NULL returns from new and handles memory
allocation errors (and there are plenty of programs that do) is silently
broken by this change.  Runtime allocation errors that were previously
handled by the program now generate uncaught exceptions, resulting in
calls to unexpected(), and -- by default, at least -- program termination.

What's worse is that the fix is nontrivial; every existing program must
add a whole new layer (and style) of control flow, wrapping code in try
blocks.  There is no automatic or mechanical process that can accomodate
this langauge change -- it must be done by hand, by analyzing and then
potentially restructuring the code.

What's even worse is that if you REALLY want this behavior, you can
get it right now, WITHOUT a language change.  Just write a new_handler
that throws xalloc for you.  I fail to see why a language change with
such sweeping implications is required.

And this came from the same committee that added a wart like ++ on
boolean types to avoid breaking existing code, even though such code
is of dubious design and could be fixed almost mechanically?

Something just doesn't add up ...

In article <2hd1vf$scf@wcap.centerline.com>,
Matt Landau <matt@centerline.com> wrote:
>In <CJnqsD.Az1@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>>If either the allocation or constructor fail, an exception will
>>be thrown. ...
>>
>>It does, however, require a completely new way of thinking:
>
>It also breaks pretty much every existing nontrivial C++ program.  Any
>program that currently checks for NULL returns from new and handles memory
>allocation errors (and there are plenty of programs that do) is silently
>broken by this change.  Runtime allocation errors that were previously
>handled by the program now generate uncaught exceptions, resulting in
>calls to unexpected(), and -- by default, at least -- program termination.
>
>What's worse is that the fix is nontrivial; every existing program must
>add a whole new layer (and style) of control flow, wrapping code in try
>blocks.  There is no automatic or mechanical process that can accomodate
>this langauge change -- it must be done by hand, by analyzing and then
>potentially restructuring the code.
>
>What's even worse is that if you REALLY want this behavior, you can
>get it right now, WITHOUT a language change.  Just write a new_handler
>that throws xalloc for you.  I fail to see why a language change with
>such sweeping implications is required.
>
>And this came from the same committee that added a wart like ++ on
>boolean types to avoid breaking existing code, even though such code
>is of dubious design and could be fixed almost mechanically?
>
>Something just doesn't add up ...
>

 And what's even more worse is that we worked hard to provide backward
compatibility, which flamers seem to ignore. If you want to restore the old
behavior of operator new you can call set_new_handler(0). This removes the
default new handler, whose behavior is to throw an exception. It's up to
your vendor to tell you whether their runtime libraries will work correctly
if you do this, and its up to you to determine whether the various libraries
that you use and that you buy in the future will work correctly if you do this.
 Writing code that works correctly both ways is a difficult task.
Sooner or later you will be using exceptions. Get used to the idea.
 -- Pete

In article <SASAYAMA.94Jan12101039@jellybean.otsl.oki.co.jp> sasayama@otsl.oki.co.jp (Kaz Sasayama =?ISO-2022-JP?B?GyRCOnsbKEI=?= =?ISO-2022-JP?B?GyRCOzNPQjkoGyhC?=) writes:
>>>>>> "John" == John Max Skaller <maxtal@physics.su.OZ.AU> writes:
>
>    John> In article <SASAYAMA.93Dec28093839@yellow.otsl.oki.co.jp>
>    John> kaz@lilia.iijnet.or.jp writes:
>    >> I have a question about `new' behavior.  What can I expect the
>    >> following program to do?  Does it continue dumping NULL's
>    >> forever, or terminate when allocation failed?  While the ARM
>    >> read that I can expect the former, G++ 2.4.5's runtime acts in
>    >> the latter way.  Which is correct?
>    >>
>
>    John>  An exception, currently called 'xalloc' will be
>    John> thrown.
>
>Can I understand that `new' does (or shall?) always return a non-NULL
>pointer when it returns?

 Yes, you can assume that if new returns you get back the
memory you asked for, and the object was correctly initialised
by the constructor as well:

 X* x = new X;

If either the allocation or constructor fail, an exception will
be thrown. So you dont worry about checking for errors at each
point one can arise, instead you write more general error handlers
that can catch and deal with categories of errors: this is
supposed to be more robust.

It does, however, require a completely new way of thinking:
C++ with exception is a new language compared to C++ without them.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

>>>>> "Markus" == Markus Theissinger <theissin@haha.gmd.de> writes:

    Markus>  According to ARM 12.5 p.280 this behaviour can be
    Markus> influenced by calling set_new_handler. So what does
    Markus> malloc do if allocation fails ?

I want to know which is correct as the default behavior of new (before
any call to set_new_handler).  If it might return NULL, I must test
the value.  If it always returns non-NULL, such a test is meaningless.

--
"An AT-compatible PC for Linux, and for all of X68000's."
Kaz Sasayama ( $B:{;3OB9( (B in Japanese) at OTSL.

I have a question about `new' behavior.  What can I expect the
following program to do?  Does it continue dumping NULL's forever, or
terminate when allocation failed?  While the ARM read that I can
expect the former, G++ 2.4.5's runtime acts in the latter way.  Which
is correct?

--
#include <iostream.h>
#include <new.h>

int
main ()
{
  for (;;)
    cerr << (void *) new int [1000000] << '\n';
}
--
"An AT-compatible PC for Linux, and for all of X68000's."
Kaz Sasayama ( $B:{;3OB9( (B in Japanese) at OTSL.

In article <SASAYAMA.93Dec28093839@yellow.otsl.oki.co.jp> kaz@lilia.iijnet.or.jp writes:
>I have a question about `new' behavior.  What can I expect the
>following program to do?  Does it continue dumping NULL's forever, or
>terminate when allocation failed?  While the ARM read that I can
>expect the former, G++ 2.4.5's runtime acts in the latter way.  Which
>is correct?
>

 An exception, currently called 'xalloc' will be thrown.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <SASAYAMA.93Dec28093839@yellow.otsl.oki.co.jp>,
sasayama@otsl.oki.co.jp (Kaz Sasayama / writes:
|> I have a question about `new' behavior.  What can I expect the
|> following program to do?  Does it continue dumping NULL's forever, or
|> terminate when allocation failed?  While the ARM read that I can
|> expect the former, G++ 2.4.5's runtime acts in the latter way.  Which
|> is correct?

 According to ARM 12.5 p.280 this behaviour can be influenced by
 calling set_new_handler. So what does malloc do if allocation fails ?

--
Markus.Theissinger@gmd.de German National Research Center for Computer Science
--

In article <1993Dec30.153026.25678@gmd.de> theissin@haha.gmd.de (Markus Theissinger) writes:

   So what does malloc do if allocation fails ?

Well, in theory, malloc simply returns NULL.  I've seen it force core
dumps however.

--
Rick Busdiecker <rfb@lehman.com> and <rfb@cmu.edu>
  Lehman Brothers     ``A classic is something that everybody wants to
  3 World Financial Center    have read and nobody wants to read.
  New York, NY 10285-0900        - Samuel Langhorne Clemens (a.k.a. Mark Twain)
  (212) 640-9419

>>>>> "John" == John Max Skaller <maxtal@physics.su.OZ.AU> writes:

    John> In article <SASAYAMA.93Dec28093839@yellow.otsl.oki.co.jp>
    John> kaz@lilia.iijnet.or.jp writes:
    >> I have a question about `new' behavior.  What can I expect the
    >> following program to do?  Does it continue dumping NULL's
    >> forever, or terminate when allocation failed?  While the ARM
    >> read that I can expect the former, G++ 2.4.5's runtime acts in
    >> the latter way.  Which is correct?
    >>

    John>  An exception, currently called 'xalloc' will be
    John> thrown.

Can I understand that `new' does (or shall?) always return a non-NULL
pointer when it returns?

--
"An AT-compatible PC for Linux, and for all of X68000's."
Kaz Sasayama ( $B:{;3OB9( (B in Japanese) at OTSL.