Chapter 18 deals with the functions called and objects created automatically during the course of a program's existence.
While we can't reproduce the contents of the Standard here (you need to get your own copy from your nation's member body; see our homepage for help), we can mention a couple of changes in what kind of support a C++ program gets from the Standard Library.
All the types that you're used to in C are here in one form or
another. The only change that might affect people is the type of
NULL: while it is required to be a macro, the definition of that
macro is not allowed to be (void*)0, which is
often used in C.
In g++, NULL is #define'd to be __null, a magic keyword
extension of g++.
The biggest problem of #defining NULL to be something like "0L" is that the compiler will view that as a long integer before it views it as a pointer, so overloading won't do what you expect. (This is why g++ has a magic extension, so that NULL is always a pointer.)
In his book Effective C++, Scott Meyers points out that the best way to solve this problem is to not overload on pointer-vs-integer types to begin with. He also offers a way to make your own magic NULL that will match pointers before it matches integers:
const // this is a const object...
class {
public:
template<class T> // convertible to any type
operator T*() const // of null non-member
{ return 0; } // pointer...
template<class C, class T> // or any type of null
operator T C::*() const // member pointer...
{ return 0; }
private:
void operator&() const; // whose address can't be
// taken (see Item 27)...
} NULL; // and whose name is NULL
(Cribbed from the published version of the Effective C++ CD, reproduced here with permission.)
If you aren't using g++ (why?), but you do have a compiler which
supports member function templates, then you can use this definition
of NULL (be sure to #undef any existing versions). It only helps if
you actually use NULL in function calls, though; if you make a call of
foo(0); instead of foo(NULL);, then you're back
where you started.
Added Note: When we contacted Dr. Meyers to ask permission to print this stuff, it prompted him to run this code through current compilers to see what the state of the art is with respect to member template functions. He posted an article to Usenet after discovering that the code above is not valid! Even though it has no data members, it still needs a user-defined constructor (which means that the class needs a type name after all). The ctor can have an empty body; it just needs to be there. (Stupid requirement? We think so too, and this will probably be changed in the language itself.)
Return to top of page or to the FAQ.
<limits>This header mainly defines traits classes to give access to various
implementation defined-aspects of the fundamental types. The
traits classes -- fourteen in total -- are all specilizations of the
template class numeric_limits defined as follows:
template<typename T> struct class {
static const bool is_specialized;
static T max() throw();
static T min() throw();
static const int digits;
static const int digits10;
static const bool is_signed;
static const bool is_integer;
static const bool is_exact;
static const int radix;
static T epsilon() throw();
static T round_error() throw();
static const int min_exponent;
static const int min_exponent10;
static const int max_exponent;
static const int max_exponent10;
static const bool has_infinity;
static const bool has_quiet_NaN;
static const bool has_signaling_NaN;
static const float_denorm_style has_denorm;
static const bool has_denorm_loss;
static T infinity() throw();
static T quiet_NaN() throw();
static T denorm_min() throw();
static const bool is_iec559;
static const bool is_bounded;
static const bool is_modulo;
static const bool traps;
static const bool tinyness_before;
static const float_round_style round_style;
};
Return to top of page or to the FAQ.
Not many changes here to <cstdlib> (the old stdlib.h).
You should note that the abort() function does not call
the destructors of automatic nor static objects, so if you're depending
on those to do cleanup, it isn't going to happen. (The functions
registered with atexit() don't get called either, so you
can forget about that possibility, too.)
The good old exit() function can be a bit funky, too, until
you look closer. Basically, three points to remember are:
atexit() are called in
reverse order of registration, once per registration call.
(This isn't actually new.)
extern "C or C++" void f1 (void);
extern "C or C++" void f2 (void);
static Thing obj1;
atexit(f1);
static Thing obj2;
atexit(f2);
then at a call of exit(), f2 will be called, then
obj2 will be destroyed, then f1 will be called, and finally obj1
will be destroyed. If f1 or f2 allow an exception to propagate
out of them, Bad Things happen.
Note also that atexit() is only required to store 32
functions, and the compiler/library might already be using some of
those slots. If you think you may run out, we recommend using
the xatexit/xexit combination from libiberty, which has no such limit.
Return to top of page or to the FAQ.
There are six flavors each of new and delete, so
make certain that you're using the right ones! Here are quickie
descriptions of new:
bad_alloc on errors;
this is what most people are used to usingbad_alloc on errorsThey are distinguished by the parameters that you pass to them, like
any other overloaded function. The six flavors of delete
are distinguished the same way, but none of them are allowed to throw
an exception under any circumstances anyhow. (They match up for
completeness' sake.)
Remember that it is perfectly okay to call delete on a
NULL pointer! Nothing happens, by definition. That is not the
same thing as deleting a pointer twice.
By default, if one of the "throwing news" can't
allocate the memory requested, it tosses an instance of a
bad_alloc exception (or, technically, some class derived
from it). You can change this by writing your own function (called a
new-handler) and then registering it with set_new_handler():
typedef void (*PFV)(void);
static char* safety;
static PFV old_handler;
void my_new_handler ()
{
delete[] safety;
popup_window ("Dude, you are running low on heap memory. You
should, like, close some windows, or something.
The next time you run out, we're gonna burn!");
set_new_handler (old_handler);
return;
}
int main ()
{
safety = new char[500000];
old_handler = set_new_handler (&my_new_handler);
...
}
bad_alloc is derived from the base exception
class defined in Chapter 19.
Return to top of page or to the FAQ.
If you have read the source
documentation for namespace abi then you are aware
of the cross-vendor C++ ABI which we use. One of the exposed
functions is the one which we use for demangling in programs like
c++filt, and you can use it yourself as well.
(The function itself might use different demanglers, but that's the whole point of abstract interfaces. If we change the implementation, you won't notice.)
Probably the only times you'll be interested in demangling at runtime
are when you're seeing typeid strings in RTTI, or when
you're handling the runtime-support exception classes. For example:
#include <exception>
#include <iostream>
#include <cxxabi.h>
struct empty { };
template <typename T, int N>
struct bar { };
int main()
{
int status;
char *realname;
// exception classes not in <stdexcept>, thrown by the implementation
// instead of the user
std::bad_exception e;
realname = abi::__cxa_demangle(e.what(), 0, 0, &status);
std::cout << e.what() << "\t=> " << realname << "\t: " << status << '\n';
free(realname);
// typeid
bar<empty,17> u;
const std::type_info &ti = typeid(u);
realname = abi::__cxa_demangle(ti.name(), 0, 0, &status);
std::cout << ti.name() << "\t=> " << realname << "\t: " << status << '\n';
free(realname);
return 0;
}
With GCC 3.1 and later, this prints
St13bad_exception => std::bad_exception : 0
3barI5emptyLi17EE => bar<empty, 17> : 0
The demangler interface is described in the source documentation linked to above. It is actually written in C, so you don't need to be writing C++ in order to demangle C++. (That also means we have to use crummy memory management facilities, so don't forget to free() the returned char array.)
Return to top of page or to the FAQ.
See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to the libstdc++ mailing list.