Almost all parts of the library are written as templates. Without template support, you can't use the standard library. Moreover, the library needed new special template features, which I introduce after a short overview of templates.

Templates are functions or classes that are written for one or more types not yet specified. When you use a template, you pass the types as arguments, explicitly or implicitly. The following is a typical example — a function that returns the maximum of two values:

   template <class T>
   inline const T& max (const T& a, const T& b)
   {
       // if a <b then use b else use a
       return  a < b ? b : a;
   }

Here, the first line defines T as an arbitrary data type that is specified by the caller when the caller calls the function. You can use any identifier as a parameter name, but using T is very common, if not a de facto convention. The type is classified by class, although it does not have to be a class. You can use any data type as long as it provides the operations that the template uses.^[3]

Following the same principle, you can "parameterize" classes on arbitrary types. This is useful for container classes. You can implement the container operations for an arbitrary element type. The C++ standard library provides many template container classes (for example, see Chapter 6 or Chapter 10). It also uses template classes for many other reasons. For example, the string classes are parameterized on the type of the characters and the properties of the character set (see Chapter 11).

A template is not compiled once to generate code usable for any type; instead, it is compiled for each type or combination of types for which it is used. This leads to an important problem in the handling of templates in practice: You must have the implementation of a template function available when you call it, so that you can compile the function for your specific type. Therefore, the only portable way of using templates at the moment is to implement them in header files by using inline functions.^[4]

The full functionality of the C++ standard library requires not only the support of templates in general, but also many new standardized template features, including those discussed in the following paragraphs.

   bitset<32> flags32;     // bitset with 32 bits 
   bitset<50> flags50;     // bitset with 50 bits

   template <class T, class container = vector<T> >
   class MyClass;

   MyClass<int> x1;          // equivalent to: MyClass<int,vector<int> >

   template <class T> 
   Class MyClass {
      typename T::SubType * ptr;
      ...
   };

   T::SubType * ptr

   MyClass<Q> x;

   class Q {
       typedef int SubType;
       ...
   };

   class Q {
       class SubType;
       ...
   };

   template <typename T> class MyClass;

   class MyClass {
       ...
       template <class T>
       void f(T);
   };

   template <class T>
   class MyClass {
     private:
       T value;
     public:
       void assign (const MyClass<T>& x) { // x must have same type as *this
           value = x.value;
       }
       ...
   };

   void f()
   {
       MyClass<double> d;
       MyClass<int> i;


       d.assign(d);   //OK
       d.assign(i);   //ERROR: i is MyClass<int>
                      //        but MyClass<double> is required
   }

   template <class T>
   class MyClass<T> {
     private:
       T value;
     public:
       template <class X>                      // member template
       void assign (const MyClass<X>& x) {      // allows different template types
           value = x.getValue();
       }
       T getValue() const {
           return value;
       }
       ...
   };


   void f()
   {
       MyClass<double> d;
       MyClass<int> i;


       d.assign(d);   // OK
       d.assign(i);   // OK (int is assignable to double)
   }

   template <class T>
   class MyClass {
     public:
       //copy constructor with implicit type conversion
//- does not hide implicit copy constructor
       template <class U>
       MyClass (const MyClass<U>& x);
       ...
   };


   void f()
   {
       MyClass<double> xd;
       ...
       MyClass<double> xd2(xd);     // calls built-in copy constructor
       MyClass<int> xi (xd);        // calls template constructor
       ...
   }

   template <class T>
   class MyClass {
       ...
       template <class T2>
       class NestedClass;
       ...
   };

If you use the syntax of an explicit constructor call without arguments, fundamental types are initialized with zero:

   int i1;             // undefined value
   int i2 = int();     // initialized with zero

This feature is provided to enable you to write template code that ensures that values of any type have a certain default value. For example, in the following function the initialization guarantees that x is initialized with zero for fundamental types:

   template <class T>
   void f()
   {
       T x = T();
       ...
   }

The C++ standard library uses exception handling. Using this feature, you can handle exceptions without "polluting" your function interfaces: arguments and return values. If you encounter an unexpected situation, you can stop the usual data processing by "throwing an exception":

   class Error;


   void f()
   {
        ...
        if (exception-condition) {
            throw Error();                 // create object of class Error and throw it as exception
        }
        ...
   }

The throw statement starts a process called stack unwinding; that is, any block or function is left as if there was a return statement. However, the program does not jump anywhere. For all local objects that are declared in the blocks that the program leaves due to the exception their destructors are called. Stack unwinding continues until main() is left, which ends the program, or until a catch clause "catches" and handles the exception:

   int main()
   {
       try {
           ...
           f();
           ...
       }
       catch (const Error&) {
           ... //handle exception
       }
       ...
   }

Here, any exception of type Error in the try block is handled in the catch clause.^[6]

Exception objects are ordinary objects that are described in ordinary classes or ordinary fundamental types. Thus, you can use ints, strings, or template classes that are part of a class hierarchy. Usually you design (a hierarchy of) special error classes. You can use their state to pass any information you want from the point of error detection to the point of error handling.

Note that the concept is called exception handling not error handling. The two are not necessarily the same. For example, in many circumstances bad user input is not an exception; it typically happens. So it is often a good idea to handle wrong user input locally using the usual error-handling techniques.

You can specify which set of exceptions a function might throw by writing an exception specification:

   void f() throw(bad_alloc);  //f() may only throw bad_alloc exceptions

You can specify that a function does not throw an exception by declaring an empty set of exceptions:

   void f() throw();           //f() does not throw

A violation of an exception specification causes special behavior to occur. See the description of the exception class bad_exception on page 26 for details.

The C++ standard library provides some general features for exception handling, such as the standard exception classes and class auto_ptr (see Section 3.3, and Section 4.2, for details).

As more and more software is written as libraries, modules, or components, the combination of these different parts might result in a name clash. Namespaces solve this problem.

A namespace groups different identifiers in a named scope. By defining all identifiers in a namespace, the name of the namespace is the only global identifier that might conflict with other global symbols. Similar to the handling of classes, you have to qualify a symbol in a namespace by preceding the identifier with the name of the namespace, separated by the operator :: as follows:

//defining identifiers in namespace josuttis
   namespace josuttis {
       class File;
       void myGlobalFunc();
       ...
   }
   ...


   //using a namespace identifier
   josuttis::File obj;
   ...
   josuttis::myGlobalFunc();

Unlike classes, namespaces are open for definitions and extensions in different modules. Thus you can use namespaces to define modules, libraries, or components even by using multiple files. A namespace defines logical modules instead of physical modules (in UML and other modeling notations, a module is also called a package).

You don't have to qualify the namespace for functions if one or more argument types are defined in the namespace of the function. This rule is called Koenig lookup. For example:

//defining identifiers in namespace josuttis
   namespace josuttis {
       class File;
       void myGlobalFunc(const File&);
       ...
   }
   ...


   josuttis::File obj;
   ...
   myGlobalFunc(obj);   //OK, lookup finds josuttis::myGlobalFunc()

By using a using declaration, you can avoid the (remaining) tedious, repeated qualification of the namespace scope. For example, the declaration

   using josuttis::File;

makes File a local synonym in the current scope that stands for josuttis::File.

A using directive makes all names of a namespace available, because they would have been declared outside their namespace. However, the usual name conflicts may arise. For example, the directive

   using namespace josuttis;

makes File and myGlobalFunc() global in the current scope. The compiler will report an ambiguity if there also exists an identifier File or myGlobalFunc() in the global scope and the user uses the name without qualification.

Note that you should never use a using directive when the context is not clear (such as in header files, modules, or libraries). The directive might change the scope of identifiers of a namespace, so you might get different behavior than the one expected because you included or used your code in another module. In fact, using directives in header files is really bad design.

The C++ standard library defines all identifiers in namespace std. See Section 3.1, for details.

To provide better support for Boolean values, type bool was introduced. Using bool increases readability and allows you to overload behavior for Boolean values. The literals true and false were introduced as Boolean values. Automatic type conversions to and from integral values are provided. The value 0 is equivalent to false. Any other value is equivalent to true.

By using the keyword explicit, you can prohibit a single argument constructor from defining an automatic type conversion. A typical example of the need for this feature is in a collection class in which you can pass the initial size as constructor argument. For example, you could declare a constructor that has an argument for the initial size of a stack:

   class Stack {
       explicit Stack(int size);      // create stack with initial size
...
   };

Here, the use of explicit is rather important. Without explicit this constructor would define an automatic type conversion from int to Stack. If this happens, you could assign an int to a Stack:

   Stack s;
   ...
   s = 40;      // Oops, creates a new Stack for 40 elements and assigns it to s

The automatic type conversion would convert the 40 to a stack with 40 elements and then assign it to s. This is probably not what was intended. By declaring the int constructor as explicit, such an assignment results in an error at compile time.

Note that explicit also rules out the initialization with type conversion by using the assignment syntax:

   Stack s1(40);        // OK
   Stack s2 = 40;       // ERROR

This is because there is a minor difference between

   X x;
   Y y(x);       // explicit conversion

and

   X x;
   Y y = x;      // implicit conversion

The former creates a new object of type Y by using an explicit conversion from type X, whereas the latter creates a new object of type Y by using an implicit conversion.

To enable you to clarify the meaning of an explicit type conversion for one argument, the following four new operators were introduced:

These operators replace the old cast techniques that use parentheses. They have the advantage of clarifying the intention of the conversion. The old casts with parentheses could be used for any of these type conversions except for dynamic_cast, so when they were used you could not formulate the exact reason for the conversion. The new operators enable the compiler to receive more information regarding the reason for the conversion and to report an error if the conversion does more than it should.

   static_cast<Fraction>(15,100)     // Oops, creates Fraction(100)

This example does not do what you might expect. Instead of initializing a temporary fraction with numerator 15 and denominator 100, it initializes a temporary fraction only with the single value 100. The comma is not an argument separator here. Instead, it is the comma operator that combines two expressions into one expression and yields the second. The correct way to "convert" values 15 and 100 into a fraction is still

   Fraction(15,100)                  // fine, creates Fraction(15,100)

It is now possible to initialize integral constant static members inside the class structure. This is useful when the constant is used in the class structure after the initialization. For example:

   class MyClass {
       static const int num = 100;
       int elems[num];
       ...
   };

Note that you still have to define space for a constant static member that is initialized within a class definition:

   const int MyClass::num;     // no initialization here

I'd also like to clarify an important, often misunderstood, aspect of the core language — namely, the only correct and portable versions of main(). According to the C++ standard, only two definitions of main() are portable:

   int main()
   {
       ...
   }

and

   int main (int argc, char* argv[])
   {
       ...
   }

where argv (the array of command-line arguments) might also be defined as char**. Note that the return type int is required because the implicit int is deprecated.

You may, but are not required to, end main() with a return statement. Unlike C, C++ defines an implicit

   return 0;

at the end of main(). This means that every program that leaves main() without a return statement is successful (any value other than 0 represents a kind of failure). Because of this, my examples in this book have no return statement at the end of main(). Note that some compilers might print a warning message regarding this or even handle it as error. Well, that's life before the standard.