Re: Unhandled exception - How to turn off!

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

not in Microsoft C++. The typeid operator documentation page makes
absolutely no mention of namespace std.

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.

Not any well-designed library. Even portions of the standard library, which
you'd think could rely on the standard library being available and used, use
templated allocators to prevent such breakage.


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

Absolutely it should. As long as the new library meets the interface
specification, everything is perfect. This is needed by a whole slew of
memory allocators (garbage collectors, electric fence, etc) to name just one
example.


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.

You've mistaken me for the OP I think.

But in any case, I choose to use parts of the standard library because they
work well and are widely available. I don't want the compiler forcing me
into a particular implementation. If the typeid keyword is inextricably
tied to a type_info type, then make that a builtin type just like int (or
wchar_t), don't call it part of a library. String literals don't return a
std::string. They return arrays of char or wchar_t (which is why wchar_t
needs to be part of the language, not part of a library).


.

Relevant Pages

  • Re: typeid operator
    ... > Andrew Koenig wrote: ... > I think the Standard in 5.2.8 says that the lvalue is returned and that ... > the lifetime of the object referred to by the lvalue is entire program. ... and for typeid to to select one at random each time typeid is ...
    (comp.lang.cpp)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: Two Questions about "strlen", "strcat" and "strcpy"
    ... >> No. zero terminated strings is the whole problem in the first place. ... > OR length prefixed strings the language would retain compatibility ... is not easily duplicated with the old standard then it will foster interest. ... The C standards committee is dead. ...
    (comp.lang.c)
  • Re: Forth Frustrations
    ... How would they even know what they are without being language lawyers? ... standard systems and a large number of nonstandard ones. ... interpreter, ... They set up four states -- HOST INTERPRETER COMPILER ...
    (comp.lang.forth)
  • Re: Is C99 the final C? (some suggestions)
    ... >> because the ANSI standard obsoleted them, and everyone picked up the ANSI ... > fixed by using another language. ... programmers managing the meaning of the symbols for more generic operators. ... According to a paper by Intel, widening multiply accounts for something like ...
    (comp.lang.c)