Chapter 4. Support
Prev | Part II. Standard Contents | Next

## Chapter 4. Support

This part 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.

## Types

### Fundamental Types

C++ has the following builtin types:

- char

- signed char

- unsigned char

- signed short

- signed int

- signed long

- unsigned short

- unsigned int

- unsigned long

- bool

- wchar_t

- float

- double

- long double

These fundamental types are always available, without having to include a header file. These types are exactly the same in either C++ or in C.

Specializing parts of the library on these types is prohibited: instead, use a POD.

### Numeric Properties

The header `<limits>` defines traits classes to give access to various implementation defined-aspects of the fundamental types. The traits classes -- fourteen in total -- are all specializations of the class template `numeric_limits` 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;
         };

### NULL

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 an expression with pointer type such as `(void*)0`, which is often used in C.

For g++, `NULL` is `#define`'d to be `__null`, a magic keyword extension of g++ that is slightly safer than a plain integer.

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. It might not even have the same size as a pointer, so passing `NULL` to a varargs function where a pointer is expected might not even work correctly if `sizeof(NULL) < sizeof(void*)`. The G++ `__null` extension is defined so that `sizeof(__null) == sizeof(void*)` to avoid this problem.

Scott Meyers explains this in more detail in his book Effective Modern C++ and as a guideline to solve this problem recommends to not overload on pointer-vs-integer types to begin with.

The C++ 2011 standard added the `nullptr` keyword, which is a null pointer constant of a special type, `std::nullptr_t`. Values of this type can be implicitly converted to any pointer type, and cannot convert to integer types or be deduced as an integer type. Unless you need to be compatible with C++98/C++03 or C you should prefer to use `nullptr` instead of `NULL`.

Prev | Up | Next
Part II. Standard Contents | Home | Dynamic Memory