2. The C++ Language

• Introduction
• Classes and Member Functions
• Constructors, Assignment, and Destructor
• Automatic Conversion and the explicit Keyword for Constructors
• Ambiguity between Function-Style Cast and Declaration
• Derivation
• Virtual Member Functions
• Static Class Members
• Templates
• "Lazy" Implicit Instantiation
• Member Templates
• Specialization and Partial Specialization
• Local Types and Keyword typename
• Dynamic and Static Polymorphism
• Name Spaces
• C Preprocessor: Include Guards and assert Macro

Introduction

Classes and Member Functions

struct A {
    int i;
};

int main() {
    A a;
    a.i = 5;
}

class A {
public:
    int i;
};

A member function looks like a normal function declaration within a class definition. It is usually placed in a header file *.h.

class A {
    int i; // private
public:
    int  get_i();
    void set_i( int n);
};

int A::get_i() {
    return i;
}
void A::set_i( int n) {
    i = n;
}

int main() {
    A a;
    a.set_i(5);
    int j = a.get_i();
}

class A {
    int i; // private
public:
    int  get_i()       { return i; }  // both inline
    void set_i( int n) { i = n; }
};

class A {
    int i; // private
public:
    int  get_i() const { return i; }  // inline and const
    void set_i( int n) { i = n; }     // inline
};

int main() {
    A a;
    a.set_i(5);
    int j = a.get_i();
    
    const A a2;      // uninitialized constant
    // a2.set_i(5);  // this is forbidden by C++ type system
                     // So, const A is currently pretty useless.
}

Constructors, Assignment, and Destructor

Three types of constructors are distinguished: default constructor, copy constructor, and all others (user defined). A constructor has the same name as the class and it has no return type. The parameter list for the default and the copy constructor are fixed. The user defined constructors can have arbitrary parameter lists following C++ overloading rules.

class A {
    int i; // private
public:
    A();             // default constructor
    A( const A& a);  // copy constructor
    A( int n);       // user defined
    ~A();            // destructor
};

int main() {
    A a1;  // calls the default constructor
    A a2 = a1;  // calls the copy constructor (not the assignment operator)
    A a3(a1);   // calls the copy constructor (usual constructor call syntax)
    A a4(1);    // calls the user defined constructor
}  // automatic destructor calls for a4, a3, a2, a1 at the end of the block

Constructors initialize member variables. A new syntax, which resembles constructor calls, allows to call the respective constructors of the member variables (instead of assigning new values). The constructor call syntax extends also to built-in types. The order of the initializations should follow the order of the declarations, multiple initializations are separated by comma.

class A {
    int i; // private
public:
    A() : i(0) {}               // default constructor
    A( const A& a) : i(a.i) {}  // copy constructor, equal to the compiler default
    A( int n) : i(n) {}         // user defined
    ~A() {}                     // destructor, equal to the compiler default
};

class Buffer {
    char* p;
public:
    Buffer() : p( new char[100]) {}
    ~Buffer() { delete[] p; }

    Buffer( const Buffer& buf) : p( new char[100]) {
        memcpy( p, buf.p, 100);
    }
    void swap( Buffer& buf) {
        char* tmp = p;
        p = buf.p;
        buf.p = tmp; 
    }
    Buffer& operator=( const Buffer& buf) {
        // Check for self-assignment, but its only an optimization
        if ( this != & buf) {
            // In general: perform copy constructor and destructor
            // Make sure that self-assignment is not harmful.
            Buffer newbuf( buf); // create the new copy
            swap( newbuf);       // exchange it with 'this'
            // the destructor of newbuf cleans up the data previously 
            // stored in 'this'.
	}
        return *this;
    }
};

Automatic Conversion and the explicit Keyword for Constructors

struct Buffer {
    Buffer( int n);  // construtor to allocate n bytes for buffer
    // ...
};

void rotate( Buffer& buf); // a function to rotate buffer cyclically

int main() {
    rotate( 5); // oops, a temporary Buffer initialized with 5 will be created
}

struct Buffer {
    explicit Buffer( int n);
    // ...
};

Ambiguity between Function-Style Cast and Declaration

struct S {
    S(int);
};

void foo( double d) {
    S v( int(d));     // function declaration
    S w = S( int(d)); // object declaration
    S x(( int(d)));   // object declaration
}

To get the second interpretation we have to disambiguate the declaration explicitly, either by using the other intializer notation as for w or by adding parentheses that exclude the function declaration as for x. (see also decl.C)

Derivation

class B : public A {
    int j;
};

int main() {
    B b;
    A a = b;
}

class B : public A {
    int j;
public:
    B( int n) : A(n) {}
    B( int n, int m) : A(n), j(m) {}
};

class B : public A {
    int j;
public:
    B( int n = 0, int m = 0) : A(n), j(m) {}
};

Virtual Member Functions

struct Shape {
    virtual void draw() = 0;
};

struct Circle : public Shape {
    void draw();
};
struct Square : public Shape {
    void draw();
};

int main() {
    Shape* s1 = new Circle;
    Shape* s2 = new Square;
    s1->draw();	            // calls Circle::draw
    s2->draw();             // calls Square::draw
}

Since we don't know the size of the actually allocated objects any more, we also have to use a virtual member function to delete the objects properly. It is sufficient to define a virtual, empty destructor in the base class. (see also Shape.C)

struct Shape {
    virtual void draw() = 0;
    virtual ~Shape() {}
};

// ... the derived shape classes

int main() {
    Shape* s1 = new Circle;
    Shape* s2 = new Square;
    s1->draw();	            // calls Circle::draw
    s2->draw();             // calls Square::draw
    delete s1;
    delete s2;
}

Static Class Members

#include <iostream.h>

struct Counter {
    static int counter;
    Counter() { counter++; }
};

int Counter::counter = 0;

int main() {
    Counter a;
    Counter b;
    Counter c;
    cout << Counter::counter << endl;
}

Static member variables are guaranteed to be initialized before main gets executed. The order of initialization for multiple static member variables is specified to be in the order of declaration in a single compilation unit, but the order is unspecified between different compilation units. This implies in particular that a class which relies on the proper initialization of a static member variable (such as our Counter example) cannot be used as a type of a static member variable in another compilation unit (see [Item 47, Meyers97] for how to get around this restriction with local static variables in global functions).

A static variable can be used to initialize a library automatically, see Automatic Library Initialization and Housekeeping.

A member function exists already only once per class, but it has a pointer (this) to the current object hidden in its parameter list. A static member function omits this pointer. It is called like a normal function using the scope operator. A static member function cannot access member variables of the object. It can only access static member variables.

struct A {
    static int i;
    int j;
    static void init();
};

void A::init() {
    i = 5; // fine
    // j = 6; // is not allowed
}

int main() {
    A::init();
    assert( A::i == 5);
}

Templates

C++ supports two kinds of templates: class templates and function templates. Templates are incompletely specified components in which a few types are left open and represented by formal placeholders, the template arguments. The compiler generates a separate translation of the component with actual types replacing the formal placeholders wherever this template is used. This process is called template instantiation. The actual types for a function template are implicitly given by the types of the function arguments at instantiation time. Therefore, all template arguments must be used somewhere in the function parameter list. An example is a swap function that exchanges the value of two variables of arbitrary types.

template <class T>
void swap( T& a, T& b) {
    T tmp = a; 
    a = b;
    b = tmp;
}

int main() {
    int i = 5;
    int j = 7;
    swap( i, j);  // uses "int" for T.
}

template <class T>
struct list {
    void push_back( const T& t); // append t to list.
};

int main() {
    list<int> ls;  // uses "int" for T.
    ls.push_back(5);
}

template <class T>
void list<T>::push_back( const T& t) { ... }

The C++ compiler uses pattern matching to derive automatically the template argument types for functions template. Consider for example a function template that works only for lists:

template <class T>
void foo( list<T>& ls);

Template arguments can have default values, e.g., a stack class built with our list. Note the space between the two > >. Otherwise this would be parsed as the right-shift operator.

template <class T, class Container = list<T> >
struct stack { ... };

Besides type parameters, class templates can also have builtin integral types as template parameters. In that case, the template arguments must be constant expression for that integral type. A useful example are points of constant dimension. The parameter is determined at compile time and thus constant. We can use it to declare a fixed size array of coordinates for the point. Features like default arguments and specialization (see below) work also on this kind of parameter.

template <int dim>
struct Point { 
    double coordinates[dim]; // coordinate array
    // ...
};

int main() {
    Point<3> // a point in 3d space
}

The C++ standard aims for separate compilation of templates, but this is not available in most compilers today. The current model for templates is that all source code including definitions goes into the header files.

"Lazy" Implicit Instantiation

Member functions of class templates are also instantiated implicitly.

Assume that we want to add a sort member function to our list template from above. Quicksort is not efficient on lists (needs an extra container), so our specialized member function realizes, for example, a more efficient merge sort. For a sort function, the item type of the list needs to be comparable. But lists in general are also useful for types that are not comparable. However, this causes no problem in C++, since C++ is not allowed to compile the sort member function if it is not instantiated somewhere. And the compiler is not allowed to complain about the missing comparison operator in the sort member function. In consequence, we can use the list class with a type that is not comparable, as long as we do not try to sort this list somewhere in our program. In the chapter on the STL we will see examples where this useful to implement generic adapters for iterators.

This behavior is restricted to class templates.

Member Templates

The small convenience class pair<T1,T2> from the STL makes use of a member template constructor. The class pair<T1,T2> contains a member variable of type T1 and a member variable of type T2, i.e., a tuple (first,second) with types (T1,T2). The default copy constructor allows the construction of a pair, if the types for the template arguments are exactly the same. However, in C++ are several automatic conversions possible, for example mutable to const, pointer of derived class to pointer of base class, short to int, etc. It would be nice, if we could create one pair from another pair, if the types T1 and T2 would be assignable from one pair to the other pair. The solution is a template constructor accepting all pairs. The actual construction of its member variable compiles only if this construction is permitted.

template <class T1, class T2>
struct pair {
    T1 first;
    T2 second;
    pair() {}  // don't forget the default constructor if there are also others
    // template constructor
    template <class U1, class U2>
    pair( const pair<U1,U2>& p);
};

template <class T1, class T2> 
template <class U1, class U2>
pair<T1,T2>::pair( const pair<U1,U2>& p) 
    : first( p.first), second( p.second) {}

Specialization and Partial Specialization

template <>
struct vector<bool> {
    // specialized implementation
};

Now suppose, vector has a second template argument for a memory allocator (which it does in the STL, but hidden by a default setting). The resulting partial specialization is still a template.

template <class Allocator = std::allocator>
struct vector<bool,Allocator> {
    // partially specialized implementation
};

Local Types and Keyword typename

template <class T>
struct list {
    typedef T value_type;
};

int main() {
    list<int> ls;
    list<int>::value_type i; // is of type int
}

template <class Container>
struct X {
    typedef Container::value_type value_type; // not correct
    // ...
};

template <class Container>
struct X {
    typedef typename Container::value_type value_type;
    // ...
};

1. denotes a type; and
2. is qualified: i.e., it contains a scope operator `::'; and
3. appears in a template; and
4. is not used in a list of base-classes or as an item to be initialized by a constructor initializer list, and
5. has a component left of a scope resolution operator that depends on a template parameter.

template<class T>
struct S : public X<T>::Base {     // no typename, because of 4
    S(): X<T>::Base(               // no typename, because of 4
        typename X<T>::Base(0)) {} // typename needed
    X<T> f() {                     // no typename, because of 2
        typename X<T>::C *p;       // declaration of pointer p, typename needed
        X<T>::D *q;                // no typename ==> multiplication!
    }
    X<int>::C *s_;                 // typename allowed but not needed
};

struct U {
    X<int>::C *pc_;                // no typename, because of 2
};

Dynamic and Static Polymorphism

Let us look at the shape example we saw earlier:

struct Shape {
    virtual void draw() = 0;
    virtual ~Shape() {}
};

struct Circle : public Shape {
    void draw();
};
struct Square : public Shape {
    void draw();
};

void display (const Shape& s) {   // dynamic polymorphism
    s.draw();
}

template <class T>                // static polymorphism
void display (const T& s) {       // T does not need to be derived from Shape
    s.draw();
}

• Heterogeneous dynamic collections are difficult to handle. For example, a drawing class might have a list of its component shapes:

  class Drawing {
      list<Shape*> components;   // relies on dynamic polymorphism
      // ...
  }
  

• Code bloat. There is a separate instance of display<T> for each type T.
• No separate compilation. Compilation of display<T> needs the definition of T.

template <class T>
void swap( T& a, T& b) {
    T tmp = a; 
    a = b;
    b = tmp;
}

struct Swappable {
    virtual Swappable* clone() const =0;
    virtual Swappable& assign(const Swappable& rhs) =0;
    virtual ~Swappable() {};
}

void swap (Swappable& a, Swappable& b) {
    Swappable* tmp = a.clone();
    a.assign(b);
    b.assign(*tmp);
    delete tmp;
}

• Built-in types cannot be handled directly.
• Inefficiency. (Virtual function call overhead, no inlining.)
• Static type checking is compromised. For example, trying to swap objects of two different types cannot be detected at compile time.

Name Spaces

As a library developer we do not own the universe, for example, for identifier names. An application programmer most likely uses more than one library and create additional identifier names. It frequently happened that common names such as min, max, swap, or Byte have been defined in more than one library with surprising results when those libraries where used together. Assume a header file "a.h" contains the macro definition

#define Byte unsigned char;

and another header file "b.h" defines

typedef unsigned char Byte;

What happens if we include both header files, does it depend on the order of inclusion?

A common way out of this dilemma was and still is the use of a common prefix for all identifiers of one library. The prefix is typically a short abbreviation such as std_, CGAL_, Q for the Qt GUI interface, and it is supposely different than all other prefixes.

In C++ we have the new concept of name spaces. They act as a scope and group identifiers together. They can be extended anytime. An example:

namespace CGAL {
    int max( int a, int b);
    class A;
    void foo( const A& a);
} // ends the namespace CGAL

We could use the above declarations in the following way:

int main() {
    int i = CGAL::max( 3, 4);
    A a; // assumes that we have also seen the full definition of A somewhere
    CGAL::foo( a);
}

So far, the name space scope CGAL:: with the so-called scope operator :: has just replaced the prefix in user code. However, within the name space itself we don't have to repeat the scope all the time. Name lookup happens following the name space scope from the inside to the outside. The global name space scope is just denoted :: and can be used to name identifiers in the global scope that also exist in the current local scope.

There is an alternative possebility for calling the function foo, see this example instead:

int main() {
    A a;
    foo( a);
}

We just omitted the scope, but now the compiler also examines the argument types and includes the scopes of the argument types for name lookup searches. This is well known in C++ under the name Koenig lookup.

All the standard C and C++ library has been enclosed in the std namespace. One can import a whole namespace or just selected identifiers into the current namespace with the using declarative:

using namespace std;
using std::vector;

C Preprocessor: Include Guards and assert Macro

C++ has inherited from C its preprocessor, a separate phase of the compiler that processes its own language before the compiler looks at the (transformed) source code. We discuss only a few aspects of the preprocessor, largely because it has almost become superfluous with the new language elements of C++, namely constants and templates.

Symbolic Constants

One can define symbolic constants, such as:

#define M_PI 3.14159265358979323846
#define CGAL_CFG_NO_KOENIG_LOOKUP 1

Each of these definitions defines a replacement rule, where the identifier following the #define gets literally replaced with the text following it. Note that this replacement happens on a text processing basis only, the preprocessor does not know about classes, protection, namespaces and scopes!

Include Guards

The preprocessor has control structures that can control which parts of the source code are compiled and which parts are excluded from the compiler.

assert Macro