   
   
   
   
   
   
Chapter 18:  Library Support 
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.
Contents
   
#1Types    
#2Implementation properties    
#3Start and Termination    
#4Verbose terminate    
#5Dynamic memory management    
#6RTTI, the ABI, and demangling Types 
   
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
      
http://www.awprofessional.com/titles/0-201-92488-9/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
      
http://www.awprofessional.com/titles/0-201-31015-5/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
      
http://groups.google.com/groups?oi=djq&selm=an_644660779an
      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 #topto top of page  or
      
../faq/index.htmlto the FAQ .
   
Implementation properties 
   
<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, documented
   
http://gcc.gnu.org/onlinedocs/libstdc  /latest-doxygen/structstd_1_1numeric__limits.htmlhere    and 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 #topto top of page  or
      
../faq/index.htmlto the FAQ .
   
Start and Termination 
   
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:
   
      
        
Static objects are destroyed in reverse order of their creation.
        
        
Functions registered with atexit() are called in
            reverse order of registration, once per registration call.
            (This isn't actually new.)
        
        
The previous two actions are "interleaved," that is,
            given this pseudocode:
            
              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 #topto top of page  or
      
../faq/index.htmlto the FAQ .
   
Verbose terminate 
   
If you are having difficulty with uncaught exceptions and want a
      little bit of help debugging the causes of the core dumps, you can
      make use of a GNU extension in GCC 3.1 and later:
   
   
   #include <exception>
   int main()
   {
       std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
       ...
       throw 
anything;
   }
   
The  __verbose_terminate_handler  function obtains the name
      of the current exception, attempts to demangle it, and prints it to
      stderr.  If the exception is derived from 
 std::exception       then the output from 
what() will be included.
   
   
Any replacement termination function is required to kill the program
      without returning; this one calls abort.
   
   
For example:
   
   
   #include <exception>
   #include <stdexcept>
   struct argument_error : public std::runtime_error
   {  
     argument_error(const std::string& s): std::runtime_error(s) { }
   };
   int main(int argc)
   {
     std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
     if (argc > 5)
       throw argument_error("argc is greater than 5!");
     else
       throw argc;
   }
   
   
In GCC 3.1 and later, this gives
   
   
   % ./a.out
   terminate called after throwing a `int'
   Aborted
   % ./a.out f f f f f f f f f f f
   terminate called after throwing an instance of `argument_error'
   what(): argc is greater than 5!
   Aborted
   %
   
The 'Aborted' line comes from the call to abort(), of course.
   
   
UPDATE: Starting with GCC 3.4, this is the default
      termination handler; nothing need be done to use it.  To go back to
      the previous "silent death" method, simply include
      
<exception> and <cstdlib>,
      and call
   
   
       std::set_terminate(std::abort);
   
Return #topto top of page  or
      
../faq/index.htmlto the FAQ .
   
   This function will attempt to write to stderr.  If your application
    closes stderr or redirects it to an inappropriate location,
    
__verbose_terminate_handler will behave in an
    unspecified manner.
Dynamic memory management 
   
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:
        
   
      
single object form, throwing a bad_alloc on errors;
          this is what most people are used to using
      
single object "nothrow" form, returning NULL on errors      
array new, throwing bad_alloc on errors      
array nothrow new, returning NULL on errors      
placement new, which does nothing (like it's supposed to)      
placement array new, which also does nothing   
   
They 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 #topto top of page  or
      
../faq/index.htmlto the FAQ .
   
RTTI, the ABI, and demangling 
   
If you have read the ../documentation.html#4source
      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 #topto top of page  or
      
../faq/index.htmlto the FAQ .
   
See 
../17_intro/license.htmllicense.html  for copying conditions.
Comments and suggestions are welcome, and may be sent to
mailto:libstdc  @gcc.gnu.orgthe libstdc++ mailing list .
