Re: Unhandled exception - How to turn off!

Ben Voigt wrote:
"Ulrich Eckhardt" <eckhardt@xxxxxxxxxxxxxx> wrote in message
news:3357d4-dmp.ln1@xxxxxxxxxxxxxxxxxxxxxxxxx
Ben Voigt wrote:
You want new to return NULL in case of failure instead of throwing?
You're now (since C++03 I think) supposed to do:

new (std::nothrow) T[N];

to get that functionality.

FYI: You have been supposed to do that since the C++ standard was
created.

Other than that, not using exception handling is IHMO stupid, you are
throwing out one of the most interesting features of C++ along with its
whole standardlibrary (which relies on exceptions).

Well, as I see it, it's linking with the standard library that should get
you the throwing behavior. Using the C runtime only, ought to get you a
version of new that doesn't throw objects in the standard C++ library.
It's against the spirit of C and C++, which is providing a very extensible
language, and functionality through libraries, not language, to have a
language keyword (new) force the user to include a particular library
(std::*).

You can't separate the standardlibrary from the language, they are already
linked e.g. via typeid() which yields a std::type_info. Also, they are both
defined by the same standard, i.e. the stuff in namespace std isn't in any
way optional, at least not as far as C++ is concerned. If you are using a
subset and modifying other things to suit your needs you are not
programming in C++ anymore. This might not matter to you, but a library
that relies on C++ features could break when used in your environment.

In any case, linking with a certain library should not change the behaviour
of existing code.

Luckily, that's only the default implementation of new, and
std::bad_alloc doesn't actually have a privileged place -- you can easily
redefine new to use your own exception type, or none at all -- and this is
important -- using the same mechanism by which the default new is
provided.

Why not simply use the existing 'new (nothrow)'? It exists and works, your
code remains standard C++ and it doesn't break other code! I'm sorry for
you if you lived under the assumption that new returned zero in case of
failure and have to change lots of code now, but this is not the fault of
the language or its implementation.

Uli

.

Relevant Pages

  • Re: read and write
    ... the C standard says otherwise. ... which are also not a part of the language. ... of these libraries are part of "C", whatever it is, since they contain ... However, any hosted implementation is required to include the entire standard C library, and prior to the standard the first edition of K&R says "Chapter 7 describes the standard C I/O library, which provides a common interface to the operating system. ...
    (comp.lang.c)
  • Re: read and write
    ... the C standard says otherwise. ... which are also not a part of the language. ... of these libraries are part of "C", whatever it is, since they contain ... common interface to the operating system. ...
    (comp.lang.c)
  • Re: Qi Seems Great
    ... Common Lisp will simply trounce anything else in the long ... but having third party libraries to support the new ... ideas come along doesn't mean that the language itself will grow. ... Having in mind that the CL standard is rather old, ...
    (comp.lang.lisp)
  • Re: [LONG] Re: Why code completion and early error checking are needed
    ... >> the programmer who wants such features. ... > libraries to find the type declaration. ... If you type std::vector that means the one from the Standard. ... > of the language to have certain naming and declaration standards ...
    (comp.lang.cpp)
  • Re: Forth and Unix -- history
    ... but modern Forths mostly drive them away. ... You have no justification to call STOIC retro nostalgia given that Standard Forth is pretty much stuck in the mid 70's. ... Users provide a large fraction of those libraries for C. Publicly. ... users must find the language comfortable in order to create such things. ...
    (comp.lang.forth)