David R Tribble <david@tribble.com> wrote in message
news:37C46642.F3953627@tribble.com...
> Many times that won't work.  If new() fails, more than likely it's
> not because you're out of memory, but because your heap has been
> trashed.  Throwing an exception usually entails instantiating a
> new object on the heap; doing so after a new() failure is foolhardy.

This depends on the quality of the implementation.  An implenetation could
preallocate an instance of bad_alloc, which would be reserved for passing
into the exception system if new() fails.  Alternatively, some "reserve"
memory could be kept around for allocation only for allocating bad_alloc
when thrown from the standard new-failure handler (although this might not
provide as much protection against a trashed heap).

> So allowing a single function to trap the first new() failure,
> which then proceeds to abort the program, is a good idea in most
> cases.  And using set_new_handler() certainly doesn't stop you
> from using try/catch elsewhere.

Calling abort is often a bad idea, especially if it means the user doesn't
get to save his work.  Throwing back to a handler that can abort the last
operation and allow user to save and exit cleanly is a good idea, if your
compiler will let you do it.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"William H. Bloodworth" wrote:
>
> On 19 Aug 99 22:42:23 GMT, "Fred Jackson" <fjackson@imetrix.com> wrote:
>
> >The latter is the case - typical Microsoft behavior.
> >
> >You can call _set_new_handler from the first line of main()
> >to register a handler you write which throws std::bad_alloc,
> >in order to get standard behavior - almost.  Interestingly,
> >nothrow works if you do this, as your handler is not called
> >when you use nothrow, which means NULL will then be returned,
> >as it should be.
> >
> >I say "almost", because this does not address operator new
> >behavior in constructors of static global classes.
> >
> >I'd be interested to hear a method of successfully dealing
> >with this latter problem.
>
> M$'s solution for setting one function as the "handler" IMO is a
> terrible solution.  If I had the opportunity (which the C++ standard
> says I should have) to catch an exception at the point where it was
> thrown I could possibly handle the situation there...not in some
> generic handler function.

Many times that won't work.  If new() fails, more than likely it's
not because you're out of memory, but because your heap has been
trashed.  Throwing an exception usually entails instantiating a
new object on the heap; doing so after a new() failure is foolhardy.

So allowing a single function to trap the first new() failure,
which then proceeds to abort the program, is a good idea in most
cases.  And using set_new_handler() certainly doesn't stop you
from using try/catch elsewhere.

-- David R. Tribble, david@tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James.Kanze@dresdner-bank.com wrote:
>
> "Fred Jackson" <fjackson@imetrix.com> wrote:
>> The latter is the case - typical Microsoft behavior.
>>
>> You can call _set_new_handler from the first line of main()
>> to register a handler you write which throws std::bad_alloc,
>> in order to get standard behavior - almost.
>
> This sounds like a sure recepe for subtle program failure.
> Presumably, Microsoft's libraries have been written expecting new
> not to throw -- it would be a miracle if they were "accidentally"
> exception safe.

Worse than that, while calling set_new_handler() is standard,
Microsoft's implementation of set_new_handler() is different than
ISO.  Their documentation, in fact, says that set_new_handler() is
worthless and to use _set_new_handler() instead, which is even more
different.

All of which makes writing portable (conforming) code for Win32
a real pain.  Will they fix it in a new release?  I'm not holding
my breath.

-- David R. Tribble, david@tribble.com --
Win95: Start me up... You make a grown man cry...
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <W8FQTKBrd$u3EwF+@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:

> Is that a serious question:) Throwing an exception has been the
> correct behaviour since 92 or 93.

Throwing an exception has been the correct behavior since 1998, not
before.  Various drafts of the standard have made it evident that this
would be the correct behavior in the final standard (although exactly
what the exception would be was not clear until much later), but as long
as there was no stable, accepted document (FDIS, at least), the only
possible reference for "correct" behavior was the ARM.  (This is not to
criticize vendors who offered intermediate versions as extensions, as
long as they were clearly labled as extensions, and ARM conformant
behavior was available.)

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7phd79$5ka$1@smaug.cape.com>,
  "Fred Jackson" <fjackson@imetrix.com> wrote:
> The latter is the case - typical Microsoft behavior.
>
> You can call _set_new_handler from the first line of main()
> to register a handler you write which throws std::bad_alloc,
> in order to get standard behavior - almost.

This sounds like a sure recepe for subtle program failure.  Presumably,
Microsoft's libraries have been written expecting new not to throw -- it
would be a miracle if they were "accidentally" exception safe.

If some vendors are unable to conform to standard, then they are unable.
Playing funny games will not miraculously make the conform.  You
basically have two choices: live with it, or find another supplier.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37bcab4d.83828499@news.airmail.net>,
  whbloodworth@usa.net wrote:

> If I had the opportunity (which the C++ standard says I should
> have) to catch an exception at the point where it was thrown I could
> possibly handle the situation there...

I'm trying to figure out what you mean by this.  When you catch an
exception, the stack has been unwound; you are no longer at the point
where the exception was throw, and you can't get back there.

And the problem in this thread is not catching the exception where it
was thrown; the problem, if I understand it correctly, is that no
exception is thrown.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The latter is the case - typical Microsoft behavior.

You can call _set_new_handler from the first line of main()
to register a handler you write which throws std::bad_alloc,
in order to get standard behavior - almost.  Interestingly,
nothrow works if you do this, as your handler is not called
when you use nothrow, which means NULL will then be returned,
as it should be.

I say "almost", because this does not address operator new
behavior in constructors of static global classes.

I'd be interested to hear a method of successfully dealing
with this latter problem.



William H. Bloodworth <whbloodworth@usa.net> wrote in message
news:37bc2cd5.6578669@news.airmail.net...
> RE: Default behavior for failure of operator new.
>
> I was under the impression that the default action in the case that 'new'
> fails to allocate the memory requested, it throws an exception (unless you
> use nothrow).  The Visual C++ 6.0 MSDN documentation states the following:
>
> "If there is insufficient memory for the allocation request, by default
> operator new returns NULL. You can change this default behavior by writing
> a custom exception-handling routine and calling the _set_new_handler
> run-time library function with your function name as its argument."
>
> Is the documentation out of date or is MS just doing whatever they want to
> do (again)?
>
> William Bloodworth
>
> =====================================================================
> = Great Achievement REQUIRES Great Effort.
> =
> = William H. Bloodworth - whbloodworth@usa."net"        ICQ: 21901934
> =====================================================================
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> Is that a serious question:)  Throwing an exception has been the correct
> behaviour since 92 or 93.

Its an all to serious question, from what I've ever found MS claims that
they have to do this to support old code in legacy apps...

> nothrow was later added to support the real needs of some users who had
> to write code that did not support exceptions being thrown.

There is an excellent discussion of this and MS compilers etc in the Deep
C++ "Voices" column on MSDN (http://msdn.microsoft.com/voices/deep.asp)

Which I highly recommend reading if you deal with C++  and exceptions in
MSVC. (article is about exception handling).

Francis, it'd be an excellent link to include in CVu, IHMO.

Regards, J
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 19 Aug 99 22:42:23 GMT, "Fred Jackson" <fjackson@imetrix.com> wrote:

>The latter is the case - typical Microsoft behavior.
>
>You can call _set_new_handler from the first line of main()
>to register a handler you write which throws std::bad_alloc,
>in order to get standard behavior - almost.  Interestingly,
>nothrow works if you do this, as your handler is not called
>when you use nothrow, which means NULL will then be returned,
>as it should be.
>
>I say "almost", because this does not address operator new
>behavior in constructors of static global classes.
>
>I'd be interested to hear a method of successfully dealing
>with this latter problem.

M$'s solution for setting one function as the "handler" IMO is a terrible
solution.  If I had the opportunity (which the C++ standard says I should
have) to catch an exception at the point where it was thrown I could
possibly handle the situation there...not in some generic handler function.
I know...I'm preaching to the choir!

If I ever meet Bill in person I think I would have to slap him!  Time to
switch to another compiler.

William Bloodworth


=====================================================================
= Great Achievement REQUIRES Great Effort.
=
= William H. Bloodworth - whbloodworth@usa."net"        ICQ: 21901934
=====================================================================
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

RE: Default behavior for failure of operator new.

I was under the impression that the default action in the case that 'new'
fails to allocate the memory requested, it throws an exception (unless you
use nothrow).  The Visual C++ 6.0 MSDN documentation states the following:

"If there is insufficient memory for the allocation request, by default
operator new returns NULL. You can change this default behavior by writing
a custom exception-handling routine and calling the _set_new_handler
run-time library function with your function name as its argument."

Is the documentation out of date or is MS just doing whatever they want to
do (again)?

William Bloodworth

=====================================================================
= Great Achievement REQUIRES Great Effort.
=
= William H. Bloodworth - whbloodworth@usa."net"        ICQ: 21901934
=====================================================================
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37bc2cd5.6578669@news.airmail.net>, William H. Bloodworth
<whbloodworth@usa.net> writes
>Is the documentation out of date or is MS just doing whatever they want to
>do (again)?

Is that a serious question:)  Throwing an exception has been the correct
behaviour since 92 or 93.

nothrow was later added to support the real needs of some users who had
to write code that did not support exceptions being thrown.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]