Advanced C++

Version 3.
1 June 2003
Advanced C++ Programming

Jean-Paul R IGAULT
Professor, University of Nice Sophia Antipolis cole Suprieure en Sciences Informatiques (ESSI) 930 route des Colles BP 145 06903 S OPHIA A NTIPOLIS Cedex France Email : jpr@essi.fr
1996-2003 Jean-Paul R IGAULT

Foreword
This document was originally designed as handouts for a third (last) year semester course at ESSI, the Computer Engineering School of the University of Nice Sophia Antipolis. The course was first given in the second semester of 1996. It has since been used in continuing education sessions on Advanced C++ in various contexts for several industrial companies. The present version (3.1) describes a C++ language which complies with the ISO C++ standard (ISO/IEC 14882:1998(E) [13]). Some features described here may not be supported event by recent C++ compilers. Most of them are known to work with gcc-2.95.3, and all of them with gcc3.2.x. The original document was in French. Only a (large) part of the course has been translated into English. Needless to say that the order for reading slides is the following:
1 3
2 4
1996-2003 Jean-Paul R IGAULT Version 3.1
II

Slides List
Foreword Slides List 0-ii 0-iii
Contents of the Course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .0-2
1.Introduction
Introduction C++ Characteristics
1-1
1-2 1-3
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
C and the Scandinavian School . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3 Origin and Influences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4 Why is C++ a Difficult Language? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
References for this Course
1-6
Indispensable Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6
2.Fundamental Mechanisms in C++
2-1
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
Objects and Types
2-3
Strong Typing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3 Strong Typing... but Implicit Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4 Strong Typing Makes Overloading Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5 Different Sorts of Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7
The C++ Class
2-8
Whats in a Class? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8 The Natural Generalization of struct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9 A Model for Creating Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11 A Model for Creating Instances: new and delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 An (Abstract) Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16 An (Abstract) Data Type: Redefining Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17 A Name Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18 A Name Space: Hierarchical in case of Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19 An Encapsulation Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20 An Encapsulation Unit: Protected Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21 A Reuse Unit through Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22 A Reuse Unit through Inheritance: virtual functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23 1996-2003 Jean-Paul R IGAULT V ERSION 3.1
III
Slides list
A Reuse Unit through Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
Objects Handling Creating, deleting, and initializing objects

A Guarantee of Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modes for Creating/Deleting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constructions/Destructions Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Construction of Built-in Scalar Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-25 2-26
2-26 2-27 2-29 2-32
Creation, Utilization, and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Copying Objects
Copy during Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Copy during Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Initialization and Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Copy: Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deep and Shallow Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preventing Copy of Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-33
2-33 2-34 2-35 2-36 2-37 2-38 2-39 2-40
3.Advanced Mechanisms and ANSI Extensions
3-1
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
Exceptions
3-3
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 Basic Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4 Basic Mechanism: Destruction of Automatic Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 Basic Mechanism: Reraising (Rethrowing) an Exception . . . . . . . . . . . . . . . . . . . . . . . . .3-6 Basic Mechanism: Uncaught Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7 Exceptions Thrown from within a Constructor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8 Throw List of a function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11 Organization of Exceptions: catch Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 Organization of Exceptions: Exceptions Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 Organization of Exceptions: Class exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15 Organization of Exceptions: Naming Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 Resource Acquisition is Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18 Termination or Resume? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20 Exceptions Should Remain Exceptional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Run Time Type Information (RTTI)

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operator dynamic_cast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class type_info and Operator typeid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bad Use of RTTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Zoology of ANSI C++ Casts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-22
3-22 3-24 3-26 3-30 3-31
Multiple Inheritance
3-34
Reminders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34 Virtual Derivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35 Construction of Virtual Base Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36
IV
Slides list
Conversions and Virtual Base Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38
Generic Functions and Classes (template)

General Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Functions: Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Functions: Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Functions: Specialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Functions: Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Classes: Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Classes: Definition of Member and Friend Functions . . . . . . . . . . . . . . . . . . . Generic Classes: Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Classes and Class Derivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Classes and Friendship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Classes: Initialization of Static Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . Member Template and Friends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Parameters for Classes and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Classes and Implicit Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explicit Instantiation of Generic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Classes: Total Specialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Classes: Partial Specialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Problem of Automatic Template Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Template Instanciation: AT&T C++/Sun CC . . . . . . . . . . . . . . . . . . . . . . . . Automatic Template Instantiation: GNU gcc 2.9x . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-40
3-40 3-41 3-42 3-43 3-44 3-45 3-46 3-47 3-48 3-49 3-50 3-51 3-53 3-55 3-56 3-58 3-59 3-61 3-63 3-65
Miscellaneous ANSI C++ Extensions

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Really Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scope of Loop Indexes; Variables in Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-66
3-66 3-67 3-68 3-72
Pointers to Class Members

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilization of Pointers to Member-Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pointers to Data Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard Conversions of Pointers to Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-73
3-73 3-75 3-76 3-77
Name Packaging (namespace)

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backwards Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class as a Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-78
3-78 3-79 3-80 3-81 3-82 3-84
References
B-1
Slides list
VI

Jean-Paul R IGAULT
Professor, University of Nice Sophia Antipolis cole Suprieure en Sciences Informatiques (ESSI) 930 route des Colles BP 145 06903 S OPHIA A NTIPOLIS Cedex France Email : jpr@essi.fr
1996, 2003 Jean-Paul RIGAULT Version 3.1
0-1

Contents of the Course
1. Introduction 2. Fundamental Mechanisms in C++ 3. Advanced Mechanisms and ANSI Extensions
0-2
1. Introduction
1-1
1. Introduction
Introduction
Summary C++ characteristics The object-oriented approach References
1-2
1. Introduction
C++ Characteristics
C and the Scandinavian School Scandinavian school of object-oriented programming Hybrid language Support for procedural (imperative) style Object-oriented features Compiled language Programming safety and run-time efficiency Maximal static analysis Upward compatible with (ANSI) C
1996, 2003 Jean-Paul RIGAULT Version 3.1 1-3
1. Introduction
C++ Characteristics
Origin and Influences
60 Fortran Algol 60 CPL Algol 68 BCPL C C with classes Simula 67 ML CLU ANSI C 70 80 Ada 90 Ada 95
C++
Eiffel Objective C
C++ ARM
C++ std
Smalltalk Lisp
Java CLOS
1-4
1. Introduction
C++ Characteristics
Why is C++ a Difficult Language? Language mechanisms are intrinsically complex Need to master the fundamental concepts of programming languages However the language is consistent and has a clear philosophy Object-orientation is a culture Stress on architecture Need to give up centralized and purely functional reflexes and habits
1. Introduction

Indispensable Books [27] The C++ Programming Language Third Edition Bjarne STROUSTRUP Addison-Wesley, 1997 [6] Advanced C++ Programming Style and Idioms James O. COPLIEN Addison Wesley, 1992 (1)
[28] The Design and Evolution of C++ Bjarne STROUSTRUP Addison-Wesley, 1994 [13] International Standard for Information Systems Programming Language C++ ISO/IEC 14882:1998(E)
1-6
1. Introduction

Indispensable Books [14] The C++ Standard Template Library Nicolai M. JOSUTIS Addison-Wesley, 1999 [25] Effective C++ CD: 85 Specific Ways to Improve your Programs and Design Scott MEYERS Addison-Wesley, 2000 [1] Modern C++ Design: Generic Programming and Design Patterns Applied Andrei ALEXANDESCU Addison-Wesley, 2001 (2)
[10] Design Patterns Elements of Reusable Object-Oriented Software Erich GAMMA et al. Addison-Wesley, 1995
(also available as a CD )
2. Fundamental Mechanisms in C++
2-1
Fundamental Mechanisms in C++

Summary Objects and Types The C++ class Objects handling Creating, deleting, and initializing objects Copying objects
2-2
Objects and Types

Strong Typing Unique type Symbolic and literal constants Variables Functions Expressions
Type of functions: prototypes (as in ANSI C) Type of an expression Can be uniquely determined from the type of its components (operands)
Objects and Types

Strong Typing... but Implicit Conversions Standard conversions Standard conversions as in C and ANSI C Standard conversions related to inheritance User-defined conversions Conversions associated with constructors
Class::Class(Type); // Type Class
Conversion operators
Class::operator Type() const; // Class Type
Objects and Types

Strong Typing Makes Overloading Possible Overloading Same name for different functions The functions differ by their parameters (number and types) The return value type plays no role
Distinguishing two functions only from their return value type would break the rule that says that the type of an expression is uniquely determined by its operand types
(1)
2-5
Objects and Types

Strong Typing Makes Overloading Possible Overloading resolution (highly simplified)
1. Search for an exact match (for parameter types) 1.1. Search for an exact exactmatch 1.2. Search for an exact match by instantiating template functions 1.3. Search for an exact match after promoting char to int (ANSI C compatibility!) 2. Search for possible standard conversions 3. Search for possible user-defined conversions
(2)
The solution must be unique Impossibility and ambiguity are detected at compile-time
Objects... And Objects

Different Sorts of Objects Base (built-in) types Pure abstract data types (no inheritance) Example: class String, class Vector... Inheritance may be used not only for subtyping (e.g., code sharing with private inheritance) Abstract data types with inheritance Public inheritance (subtyping) Possibility of dynamic binding (virtual functions, inheritance polymorphism)
The C++ Class

Whats in a Class? A natural generalization of struct A model for creating instances A type definition (an Abstract Data Type) The set of its instances (the class extension) A name space An encapsulation unit A reuse unit (through composition and inheritance) An object (not really in C++!) ...
The C++ Class

The Natural Generalization of struct A class is a like a C++ struct with additions member-functions access control initialization/cleaning up control inheritance In fact, a struct in C++ is just a class, but
all its members are public by default, inheritance level is also public by default thus a C++ struct may have member-functions, constructors, destructor, operators, private members...
(1)
The C++ Class

The Natural Generalization of struct What about C union in C++? They are defined as a struct where all the members have the same address They can have constructors and destructors and (non static) member-functions Note that a C++ class with constructors or destructor cannot be a member of an union
Since the type of the current member of the union is not memorized, the compiler would not know what to destroy...
(2)
The C++ Class

A Model for Creating Instances Internal data structure Underlying C structure Initialization and cleanup operations Constructors and destructor Redefinition and/or overloading of dynamic creation/ deletion operator new and operator delete Recall than these operators correspond to only one way of creating/deleting instances in C++ (out of 4 ways)
The C++ Class

A Model for Creating Instances: new and delete Redefining global operators Prototypes
void *operator new(size_t); void operator delete(void *);
(1)
Utilization
A *pa = new A(...);
Generated code
// allocation A *pa = (A *)operator new(sizeof(A)); // initialisation pa->A::A(...);
The C++ Class

A Model for Creating Instances: new and delete Redefining new and delete for a class (hierarchy) Prototypes
class A { public: void *operator new(size_t); void operator delete(void *); ... };
(2)
These member-functions are static They are usable only for allocating/deallocating individual objects of class A (see further)
The C++ Class

A Model for Creating Instances: new and delete Overloading global/class operators Prototypes
void *operator new(size_t, T1, T2, ...);
(3)
Utilization
A *pa = new (t1, t2, ...) A(...);
Operator new with pre-placement (predefined)

#include <new> void *operator new(size_t, void *); The object is allocated at the given address (second parameter) The programmer is responsible for allocating storage
The C++ Class

A Model for Creating Instances: new and delete Allocating/Dealloacating arrays The previous (either global or class) operators can only be used for allocating individual objects For arrays, one must use
void *operator new[](size_t); void operator delete[](void *, size_t);
(4)
Usage
A *pa = new A[n]; delete[] pa;
The array element type must have a default constructor

The C++ Class

An (Abstract) Data Type Regard instances as first class citizen Define the new type according to three viewpoints: Internal representation of instances
Underlying C structure
Legal operations on instances

Member-functions (methods) and friends Basic operators redefinition
Objects common to all instances of the type (class static variables and member-functions)
The C++ Class

An (Abstract) Data Type: Redefining Operators No new notation for operators No modification of precedence or associativity No modification of the number of operands No redefinition for built-in types All operators are redefinable, except: Preprocessor operators: # ## Compile-time operators: typeid sizeof :: The three following operators: . .* ?:
However, note that -> and ->* can be redefined
The C++ Class

A Name Space
class List { private: static int nb_lists; enum {N1, N2}; class Cell { int info; Cell *next; ... }; Cell *first; Cell *last; public: ... };
// List::nb_lists // List::N1, List::N2 // List::Cell
// this->first // this->last
2-18
The C++ Class

A Name Space: Hierarchical in case of Inheritance
class A { public: int i; int j; int n;}; class B : public A {private: int j;}; class C : public B { private:int k; public: void f(double); }; int i; // global variable void C::f(double n) { k = 0; // C::k n = 3.14;// function parameter j = 2; // B::j, but not accessible here i = 3; // A::i i = ::i;// ::i is the global i }
The C++ Class

An Encapsulation Unit Three levels of access control for members private: exclusively private to the class protected: private to the class and its derivatives public: visible and manipulable within any context Three levels of derivation : inherited members status private: protected and public private protected: public protected public: protected and public remain so For class the default is private, for struct it is public
2-20
The C++ Class

An Encapsulation Unit: Protected Members
class A {protected: int prot;}; class B1 : public A {}; class B2 : public A { public: void f(void); }; class C : public B2 {};
A B1 B2 C
void B2::f(void) A a; B1 b1; B2 prot = 1; a.prot = 2; b1.prot = 3; b2.prot = 4; c.prot = 5; }

{ b2; C // OK // KO // KO // OK // OK
c; : this->prot : no conversion A B2 : no conversion B1 B2 : b2 is a B2 ! : conversion C B2
2-21
The C++ Class

A Reuse Unit through Inheritance Static reuse mechanism Reusing the interface or the implementation Interface reuse (public derivation) should satisfy the substitutability principle (subtyping)
B is a subtype of A if any instance of A may be replaced by an instance of B The substitutability principle expresses the static semantics of inheritance (subtyping)
Implementation reuse often utilizes private inheritance

The C++ Class

A Reuse Unit through Inheritance: virtual functions
Figure surface() rotate() Ellipse surface() Rectangle surface()
class Figure { public: virtual double surface() const = 0; virtual void rotate(); }; class Ellipse : public Figure { public: double surface() const { return PI*a*b; } };
Circle rotate()
Square
Figure *pf = new Circle(...); double s = pf->surface();
2-23
The C++ Class

A Reuse Unit through Composition Composing with an instance (aggregation) Different composites cannot share components The composite is responsible for its components The lifetimes of the composite and its components are identical Composition with a pointer or a reference Make dynamic typing possible when delegating Sharing is possible Objects (component and composite) may be independent
Objects Handling
Creation, Utilization, and Implementation Implementation Internal details Their knowledge is not needed for creating/using objects Utilization (and deletion!) Either the type of the object is known (static typing) Or dynamic typing (polymorphism) is used, and knowing a super-type of the object is enough Creation The exact type of the object must be known
Creating, deleting, and initializing objects

A Guarantee of Initialization If a class has constructors, one if them will be invoked each time an instance is created If the constructor requires parameters they must be provided when creating objects Otherwise the class must be constructible by default
Either it has a default constructor Or it has no constructor at all: its base class and all its members must be constructible by default
There is no guarantee of cleanup (destructor call) for the objects created by new

Modes for Creating/Deleting Objects Static objects (permanent lifetime) Local or global (possibly external) Automatic objects (block lifetime) Always local to a block Dynamic objects Allocated by new, access through pointers No automatic deletion Exception objects Created by throw
(1)

Modes for Creating/Deleting Objects (2)
All created objects have the guarantee of initialization (call to one constructor) All objects have the guarantee of cleanup (call to the destructor) except dynamically allocated ones Static objects are destroyed at the end of the program execution (exit()) Automatic objects are destroyed at the end of their block of definition Exception objects are destroyed when they are no longer needed (end of the catch clause)

Constructions/Destructions Order Construction order
1. 2. 3. 1. 2. 3. Construction of base classe(s) Construction of class own members Constructor body Destructor body Destruction of class own members Destruction of base classe(s)
(1)
Destruction order (inverse order)
2-29

Constructions/Destructions Order Base classes are constructed in the order of the derivation list Members are constructed in the order of their declaration in the class definition
Attention! DANGER !
class B : public A1, public A2 { private: int *pt; int dim; public: B(int n) : dim(n), A1(n), pt(new int[dim]) {...} // pt(new int[n]) would be correct! };
(2)

Constructions/Destructions Order
class B {public: B(int = 0); ...};
(3)
A
class A {private: int p; public: A(int = 0); ... }; class A1 : public A { protected: B b1; public: A1(int i = 0, int j = 1) : b1(i), A(j) {...} ... }; class A2 : public A1 {private: B b2;}; A1 a1(2, 3); A2 a2;
A1
A2

Default Construction of Built-in Scalar Types A default constructor is defined for built-in scalar types
that is for integral types (char, int and all their variations, and pointers) and real types (float and double)
This default constructor is not called by default!!!

int g; // static initialization: g initialized to 0 void f() { int a = int(); // a initialized to 0 int b; // b not initialized by default!! int *p1 = new int; // *p1 not initialized by default!! int *p2 = new int(); // *p2 initialized to 0 int *p3 = new int(14); // *p2 initialized to 14 }
Copying Objects
Copy during Initialization Copy constructor
T::T(const T&) const is optional
This constructor is invoked each time an object is created as a copy of another object of the same type Simple initialization (during definition) Passing parameters to and returning from functions by value Default copy of classes with no copy constructor(s) (see later)
Copying Objects
Copy during Assignment Copy assignment operator
const T& T::operator=(const T&)
This operator is invoked each time an object is assigned to another object of the same type Simple assignment Default copy of classes with no assignment operator (see later)
2-34
Copying Objects
Initialization and Assignment An assignment is not an initialization There is exactly one initialization throughout the entire life of an object Initialization is always possible (once) whereas assignment may be forbidden (const objects) Assignment must take care of the previous state of the object whereas, for initialization, there is no such thing as a previous state An assignment trap: Beware: x = x;
Copying Objects
Default Copy If a class has copy constructor(s) and/or assignment operator, these functions are entirely responsible for copying objects Otherwise, default copy is performed memberwise Each member is copied according to its own copy semantics Base class(es) are considered as members during the copy operation The memberwise procedure is applied recursively Built-in types are copied bitwise
Copying Objects
Default Copy: Example
class Symbol { private: String _name; Value _val; public: // No copy constructor }; Symbol sy1(...); Symbol sy2 = sy1;
Symbol String Value
sy2._name is initialized from sy1._name, most likely by class String copy constructor If class Value has a copy constructor, this constructor is used to initialize sy2._val from sy1._val; otherwise the inside of type Value, is examined memberwise...
Copying Objects
Deep and Shallow Copy Deep Copy All components are copied, recursively Shallow copy Necessary when components are shared Demand the redefinition of copy operations If sharing is used, it must be explicitly handled Memberwise copy looks like deep copy but may be in fact intermediate Everything depends on member copy semantics
Copying Objects
Value Semantics A class has value semantics iff Copy operations are defined (possibly by default) Everything is as if each instance conveys its own value (lvalue/rvalue as in C) Value semantics is not incompatible with an implementation using sharing Example: class String with copy-on-write
2-39
Copying Objects
Preventing Copy of Objects To forbid copying objects for a class, make copy operations (copy constructor and copy assignment operator) private
Of course, this forbids copy only outside the class implementation A bullet-proof solution is to declare the copy operation but not to implement it: any attempt to copy will lead to a link error
class Non_Copiable { private: Non_Copiable(const Non_Copiable&); // No body definition Non_Copiable& operator=(const Non_Copiable&); // No body definition ... };
3. Advanced Mechanisms and ANSI Extensions
3-1
Advanced Mechanisms and ANSI Extensions

Summary Exceptions Run Time Type Information (RTTI) and new casts Multiple inheritance Generic functions and classes (template) Miscellaneous ANSI C++ extensions Pointers to class members Name packaging (namespace)
3-2
Exceptions
Motivation Exceptions are mandatory because of encapsulation What can be done when an abnormal condition is detected inside a class? Notify the user Allow her to recover and resume the program at a suitable point Separate normal processing from exceptional one Respect the C++ creation/deletion semantics
setjmp/longjmp are not sufficient because local variables with destructor must be destroyed properly
Exceptions
Basic Mechanism
main() {f();} void f() { try { ... g(); } catch (E1) {...}; catch (E2) {...} } void g() { try { ... h(); } catch (E1) {...} } void h() { if (...) throw E1(); else throw E2(); }
1996, 2002 Jean-Paul Rigault Version 3.1
An exception is a temporary object (of any type) When an exception is raised (thrown) the current function is exited, and the exception is propagated upward, traversing (and exiting) functions in the calling chain The propagation is stopped by the first try block with a catch for the (type of) the exception The catch clause is executed; if it does nothing special, control is then transferred after the try block (and all its catch clauses)
3-4
Exceptions
Basic Mechanism: Destruction of Automatic Objects
void f() { try { ... g(); } catch (E1) {...}; } void g() { String s("hello"); h(); ... } void h() { String s1("salut"); ... if (...) throw E1(); }
If a function is traversed by a propagated exception, all automatic (local) objects are properly destroyed (i.e., their destructor gets invoked)
deletion of s
Nothing similar happens for dynamically allocated objects (allocated by new) Thus it is the programmers responsibility to provoke the destruction of dynamically allocated objects (see later)
3-5
deletion of s1
Exceptions
Basic Mechanism: Reraising (Rethrowing) an Exception
main() {f();} void f() { try { ... g(); } catch (E1) {...}; } void g() { try { ... h(); } catch (E1) {...; throw;} } void h() { if (...) throw E1(); }
In a catch clause, using throw without parameter simply repropagates the current exception upwards
3-6
Exceptions
Basic Mechanism: Uncaught Exceptions If no try block in the calling chain has a catch clause for the current exception, the standard function terminate() is called By default, terminate() simply calls abort() But the user may provide her own version
3-7
Exceptions
Exceptions Thrown from within a Constructor (1)
All members fully constructed before the exception is thrown are deleted The destructors of fully constructed components are correctly called Partially constructed sub-objects are not destructed It is indispensable to understand clearly in which order constructions/deletions are performed It is not a good idea to throw an exception from within a destructor!
Exceptions
Exceptions Thrown from within a Constructor
class A1 { String id; public: A1(const String& s) : id(s) {} }; class A2 { int val; public: A2(int v) {if (v==0) throw Invalid();} }; class B : public A1, public A2 { String name; public: B(const String& s, int v) : A1(s), A2(v) {name = s; throw Exception_B();} };
(2)
What happens when constructing a B: If v = 0? If v 0?

Exceptions
Exceptions Thrown from within a Constructor Function try block
void f() try { function-body } catch (E1) { ... } catch (E2) { ... } ...
(3)
Particularly useful for constructors

void A::A() try : initialization-list {
constructor-body
} catch (E1) { ... } ...

Exceptions
Throw List of a function It is possible to specify the list of exceptions that a (member or regular) function may throw
void f() throw (E1, E2); void g() throw (); // no exception void h(); // any exception
C++ only requires a dynamic check Static checking is possible but delicate If an exception forbidden by the throw list is thrown, unexpected() is called (and by default abort())
Exceptions
Organization of Exceptions: catch Resolution For a same try block, catch clauses are scanned from top to bottom Type conformance must be exact, except that standard conversions related to inheritance (only) are authorized The temporary object created by throw may be retrieved in catch, by value but also by reference
catch (Stack::exception& e) {...} Above, dynamic typing may be honored for e
The form catch (...) captures all exceptions

Exceptions
Organization of Exceptions: Exceptions Hierarchy
exception
(1)
system_err
arithmetic_err
IO_err
zero_divide
overflow
underflow
file_err
network_err
Class exception is not indispensible However it is defined in the standard library

3-13
network_file_err
Exceptions
Organization of Exceptions: Exceptions Hierarchy (2)
try { ... } catch (overflow& ov) {...} catch (arithmetic_err& e) {cout << e.what();} catch (file_err) {...} catch (IO_err) {...} catch (...) {cout << "unexpected exception";} Be careful with catch order!
3-14
Exceptions
Organization of Exceptions: Class exception Defined in the ANSI standard
class exception { public: exception() throw (); exception(const exception&) throw (); exception& operator=(const exception&) throw (); virtual ~exception() throw (); virtual const char *what() const throw (); };
(1)
3-15
Exceptions
Organization of Exceptions: Class exception (2)
exception
logic_err
runtime_err
domain_error
invalid_argument out_of_range
length_error
overflow_error
range_error
3-16
Exceptions
Organization of Exceptions: Naming Exceptions
class Stack { public: class All : public My_Lib_Except {...}; class Full : public All {...}; class Empty : public All {...}; ... }; try { ...; st.push(v); ... } catch (Stack::Full) {...} catch (Stack::All) {...}
3-17
Exceptions
Resource Acquisition is Initialization
void f1() { FILE *fp = fopen("toto", "w"); ... fclose(fp); } void f2() { String *ps = new String("hello"); ... delete ps; } void f3() { Sema.P(); ... Sema.V(); }
(1)
Who is going to call fclose if an exception traverses this function? Who is going to delete ps if an exception traverses this function? Who is going to release the semaphore (Sema.V()) if an exception traverses this function?
3-18
Exceptions
Resource Acquisition is Initialization
class My_File { FILE *fp; public: My_File(...) {fp = fopen(...);} ~My_File() {fclose(fp);} }; class Handle { String *ps; public: Handle(...) {ps = new String(...);} ~Handle() {delete ps;} }; class Lock { Semaphore& sema; public: Lock(Semaphore& s) : sema(s) {sema.P();} ~Lock() {sema.V();} };
(2)
void f1() { My_File mf("toto", "r"); ... // No more need to call fclose() } void f2() { Handle h("hello"); ... // No more need to delete the String } void f3() { Lock l(Sema); ... // No more need to free the semaphore }
3-19
Exceptions
Termination or Resume? C++ exceptions are propagated upward the calling chain Moreover if the catch clause itself does not contain a transfer instruction, control resumes at the end of the try block where the exception was caught
The end of the try block means after the last catch clause of the block
Therefore it is impossible to resume execution where the exception was thrown (i.e. just after throw) Everything is as if the calling chain had been lost
Exceptions
Exceptions Should Remain Exceptional Exceptions should be reserved to exceptional situations! This is largely a matter of context
while ((c = getchar()) != EOF) {...}
Above, the end of file is an expected (and wished) event

try{ read(fd, &data_size, sizeof(int)); read(fd, buffer, data_size); } catch(End_Of_File) {...}
Above something to read was normally expected; indeed, here the end of file is exceptional

Motivation Make downward cast safe
class A { public: ... }; class B : public A { public: void f(); // not in A }; A *pa = ...; // may be pa points to a B? pa->f(); // FORBIDDEN: no method f() in A ((B *)pa)->f(); // OK, but is it reasonnable?
(1)
3-22

Motivation (2)
Run Time Type Information has not to be built-in, since we have already virtual functions However it is more comfortable and safer to delegate its implementation to the compiler Generally the RTTI mechanism is only relevant when accessing objects through pointers or references In other cases, static typing is performed
3-23

Operator dynamic_cast Use with a pointer p
T *pt = dynamic_cast<T *>(p)
(1)
Return 0 if p does not point to an object of type T or (publicly) derived from T; otherwise return the cast result Use with a reference r
T& rt = dynamic_cast<T&>(r);
Throw exception bad_cast if r does not reference an object of type T or (publicly) derived from T Require that T be a polymorphic type

Operator dynamic_cast
class Figure { public: virtual void rotate(int); virtual int surface() const; virtual void draw() const; }; class Ellipse : public Figure { public: Ellipse(Point c, int a, int b); int a_axis() const; int b_axis() const; }; class Circle : public Ellipse { public: Circle(Point c, int r) : Ellipse(center, r, r) {} int radius() const; };
(2)
Figure *pf1 = new Circle(c0, R); Figure *pf2 = new Ellipse(c1, A, B); Ellipse *pe; Circle *pc; x = pf1->a_axis();// NO pe = dynamic_cast<Ellipse *>(pf1); // pe != 0 x = pe->a_axis();// YES... now pc = dynamic_cast<Circle *>(pf2); // pc == 0 pc = dynamic_cast<Circle *>(pf1); // pc != 0 char *p = dynamic_cast<char*>(pf1); // does not compile since char is // not polymorphic
3-25

Class type_info and Operator typeid (1)
Once dynamic_cast built into the language, the path is short to dynamic type identification A type descriptor (an instance of the predefined class type_info) is associated with each type (and thus with each class) Operator typeid returns a reference to the type descriptor of its parameter
const type_info& typeid(type-name); const type_info& typeid(expression);
3-26

Class type_info and Operator typeid Class type_info (#include <typeinfo>)
class type_info { public: virtual ~type_info(); bool operator==(const type_info&) const; bool operator!=(const type_info&) const; bool before(const type_info&) const; // !! const char *name() const; // No public constructor // No public copy operator };
(2)
3-27

Class type_info and Operator typeid
Figure *pf = new Circle(...); typeid(pf) == typeid(Figure *) typeid(pf) == typeid(Ellipse *) typeid(pf) == typeid(Circle *) typeid(*pf) == typeid(Figure) typeid(*pf) == typeid(Ellipse) typeid(*pf) == typeid(Circle) // yes // no // no // no // no // yes
(3)
3-28

Class type_info and Operator typeid typeid and dynamic_cast behaves like virtual functions A virtual function is statically bound when called from within a base class constructor (and destructor)
class A {public: A(void; ...}; class B : public A {...}; A::A() if // if // } { (typeid(*this) == typeid(B)) ... FALSE, even when we are constructing a B (dynamic_cast<B *>(this) != 0) ... still FALSE, even when we are constructing a B
(4)
3-29

Bad Use of RTTI
void f(Figure *pf) { if (typeid(*pf) == typeid(Ellipse)) // do what is needed for an Ellipse else if (typeid(*pf) == typeid(Circle)) // do what is needed for an Circle else if (typeid(*pf) == typeid(Rectangle)) // do what is needed for an Rectangle else ... } In such a case, use virtual functions!

The Zoology of ANSI C++ Casts static_cast : a cast using only compile-time information
T1 t1; T2 t2 = static_cast<T2>(t1);
Contrarily to dynamic_cast, static_cast uses only static (compile-time) information Respect const and access control Not a dynamic mechanism, thus unsafe; it always returns something, possibly a nonsense If the cast is possible with only static information, it returns the correct value, even in case of ordinary multiple inheritance the result is always correct if the cast corresponds to an implicit conversion this cast must not be used in case of virtual multiple inheritance for downward casting
(1)

The Zoology of ANSI C++ Casts reinterpret_cast : the wild cast
T1 t1; T2 t2 = reinterpret_cast<T2>(t1);
(2)
T1 and T2 may have any pointer type or, more generally, any integral type This cast is intrinsically unsafe
it respects const (this is almost its only guarantee!) No adjustment of the value returned in case of multiple inheritance (contrarily to static_cast) The only sensible use is as a conversion relay (convert into some type, then backward to the original type)

The Zoology of ANSI C++ Casts (3)
const_cast : the cast to turn constants into variables

void f(const char *s, volatile int *pv) { char *pc = const_cast<char *>(s); int *pi = const_cast<int *>(pv); ... }
The target type must be the original type but without const or volatile If the object is actually constant or actually volatile, the result is undefined!
Reminders The same class cannot appear several times as a direct base class The inheritance graph must be acyclic (DAG) Ambiguities are detected at compile time (provided that they are effective) and must be statically resolved If a class appears as a base class through several inheritance paths, the default is to have (in the derived class) as many copies of the base class as there are inheritance paths If only one copy is suitable, use virtual derivation
Virtual Derivation
class Vehicule { public: virtual double speed() const; ... }; // Suppose the following two classes // do not redefine speed() class Plane : virtual public Vehicule {...}; class Boat : virtual public Vehicule {...}; class Sea_Plane : public Plane, public Boat {...}; Sea_plane sp(...); v = sp.speed(); // No ambiguity here
Construction of Virtual Base Classes (1)
Virtual base classes must be constructed exactly once (as any C++ object) They are constructed before any regular base class Thus they must Either be constructible by default Or be (explicitly) constructed by any (concrete) derivative, whatever how deep this derivative is in the hierarchy
3-36
Construction of Virtual Base Classes
class A { public: A(int); // no default construction }; class B : virtual public A {...}; class C : public B { public: C(int i): A(i), B(...) {...}// C must construct its base A }; class D: public C{ public: // D must also construct A : D(int i): A(i), C(i){...} // the usual construction // relay does not work! };
(2)
Conversions and Virtual Base Classes
class class class class A {...}; B1 : public virtual A {...}; B2 : public virtual A {...}; C : public B1, public B2 {...};
(1)
A* B1* B2* C* B2
class A
members specific to B1 members specific to B2 members specific to C
B1
B2
Just a principle outline
C
3-38
Conversions and Virtual Base Classes (2)
The complexity of conversions and addressing explains why virtual derivation is not the default in C++ Note that pointers to members take into account this complexity Operator dynamic_cast makes downward cast possible for virtual base classes
static_cast does not give a correct result in case of virtual inheritance
3-39

General Picture Possibility to create functions and classes templates parametrized (mainly) with types Two different mechanisms for functions and classes Although somewhat homogenized by ANSI C++ Static resolution (compile and link time)
3-40

Generic Functions: Definition Only one representation of identical operations, but on different types
template <typename T> inline T Min(T a, T b) { return a < b ? a : b; }
T denotes here any C++ type (class or built-in)... ... as long as the type has operator < and a copy constructor (possibly defined by default)

Generic Functions: Instantiation Instantiation is generally implicit
int i, j; char x, y; j = Min(i, 3); y = Min(x, y); // int Min(int, int) // char Min(char, char)
Implicit instantiation is within the responsibility of overloading resolution
3-42

Generic Functions: Specialization The previous form of Min is not suitable for C character strings Of course, the programmer may provide a regular function that will supersede template instantiation because exact exact match precedes template instantiation during overloading resolution
char *Min(char *s1, char *s2) { return strcmp(s1, s2) < 0 ? s1 : s2; } Note that this is different from template specialization (further)

Generic Functions: Utilization Generic functions are perfect replacement for the preprocessor macros with parameters
#define Min(a, b) ((a) < (b) ? (a) : (b))
By the way: eradicate most preprocessor use in C++

#define N 100 #define F(a) ... #define G(a) ... const int N = 100; inline F(int a) {...} template <typename T> inline T G(T a) {...}
There may remain only lexical and syntactic uses of the preprocessor

Generic Classes: Definition One unique representation of a set of classes that differ only by the types of objects they manipulate or possibly by some constants
template <typename Elem> class List {...};
template <typename Elem, int N> class Fixed_Array { Elem tab[N]; ... };

Generic Classes: Definition of Member and Friend Functions
template <typename Elem> class List { public: List(); void append(const Elem& e); friend ostream& operator<< <>(ostream&, const List<Elem>&); ... }; template <typename Elem> void List<Elem>::List() {...} template <typename Elem> void List<Elem>::append(const Elem& e) {...} template <typename Elem> ostream& operator<<(ostream& os, const List<Elem>& l) {...}
3-46

Generic Classes: Instantiation Generic class instantiation must be explicit
List<int> l1; List<List<int> > l2; // attention: > > Fixed_Array<double, 1000> fa1; Fixed_Array<List<int>, 100> fa2; List<Fixed_Array<List<char>, 10> > l3; typedef List<int> List_int; List_int l4;
3-47

Generic Classes and Class Derivation Both mechanisms are totally compatible
template <typename T> class A {...}; template <typename T> class B : public A<T> {...}; template <typename T> class Shared : public T {int refcnt; ...}; class C : public A<int> {...}; template <typename T> class D : public C {...};

Generic Classes and Friendship Friendship with all generic instances
template <typename T> class Vector { friend void f(); ... }; void f() {...}
Friendship with a specific generic instance

template <typename T> class Vector { friend void g<>(T); friend void h<>(const Vector<T>&); ... }; template <typename T> void g(T t) {...}

Generic Classes: Initialization of Static Members
template<typename T> class A { static T s; }; template <typename T> T A<T>::s = T(); // This initialization must be in the // same scope as the definition of the class
Omitting this initialization causes a link-time error
3-50

Member Template and Friends Member Template (cannot be virtual)
class A { ... template <typename U> void mt(U u, ...); ... }; template <typename U> void A::mt(U u, ...);
(1)
Member template of a template class (cannot be virtual)

template <typename T> class A { ... template <typename U> void mt(U u, ...); }; template <typename T> template <typename U> void A<T>::mt(U u, ...);

Member Template and Friends Template friend
class A { ... template <typename U> friend void tf(U u, ...); ... }; template <typename U> void tf(U u, ...);
(2)
Template template friend

template <typename T> class A { ... template <typename U> friend void tf(U u, ...) { ... } // better be defined inline! ... };
3-52

Generic Parameters for Classes and Functions ANSI C++ unifies the parameter possibilities for template functions and classes A generic parameter may be A type (built-in or class) A static constant of any integral type (this includes enum and also pointers to functions and pointers to members) Another generic class Default values are possible
(1)

Generic Parameters for Classes and Functions (2)
template <typename T, void (*SORT)(T, T[])> class Sortable {...}; void sort(int, int[]); Sortable<int, sort> s(...); template <typename T = int, int N = 10> class Fixed_Array {...};
template <typename U, template <typename T> class Container = list> class Something {...}; ... Something<int, vector> sth;

Generic Classes and Implicit Conversions Is there an implicit conversion from List<int> to List<double>? Let French be a class derived from Human. Is there an implicit conversion from Set<French> to Set<Human>? The answer is NO for both questions Should the answer be yes, contravariance (and thus the substituability principle) would be violated Two generic instances represent different types as soon as their (effective) generic parameters are different

Explicit Instantiation of Generic Functions Introduced by ANSI C++ Necessary for generic functions without type parameter Useful help for the compiler and the linker Compilers know they must generate code here
template class List<int>; template void List<int>::append(const int&); // template void List<int>::append; template int Min<int, int>(int, int); // template Min<int, int>;
(1)

Explicit Instantiation of Generic Functions Needed when the compiler cannot guess how to instantiate the template
template <int N> void f(); f(); // which value for N? f<10>(); // OK double x = Min(5, 7.2); double x = Min<double>(5, 7.2); // ambiguity // OK
(2)
Beware: possible syntactic ambiguities

template <int N> void f(int); i = f<3>(j); // it can be: (f<3) > (j) i = template f<3>(j); // OK

Generic Classes: Total Specialization It is possible to provide a specialized version of a generic class The specialized version supersedes generic instantiation
template <> class List<char *> { // Something which should // look like List<T> with T = char *, // although this is not necessary // (for C++) };

Generic Classes: Partial Specialization
template <typename T, typename I> class Vector { ... T& operator[](I index); }; template <> // Total specialization class Vector<void *, int> { ... void *& operator[](int index); }; // Note: no template <> void *& Vector<void *, int>::operator[](int index) { ... } template <typename T>// Partial specialization class Vector<T *, int> : public Vector<void *, int> { ... T*& operator[](int index); }; template <typename T> T *& Vector<T *, int>::operator[](int index) { ... }
(1)

Generic Classes: Partial Specialization Any template function or class may be totally specialized Only classes may be partially specialized Regular functions and member functions cannot The specializations must be in the same namespace as the template definition See namespace further (2)
3-60

The Problem of Automatic Template Instantiation The C++ compiler must generate code for the instantiation of generic functions and classes The user (instantiator) of a class usually sees only the class specification (.H). Where is the compiler supposed to find the body (.C)?
Use the ISO C++ export facility? Few compilers support it Find automatically the .C file in the include search path (-I option)? Use a configuration file? Put everything into the .H file (include .C into .H)?
(1)

The Problem of Automatic Template Instantiation (2)
In which object-file (.o) must the compiler generate the corresponding binary code? Generate static functions in the current compilation unit?
the code for the same template instance will be duplicated in several compilation units
Generate template code by demand in some repository and use a pre-link processor? Generate special code in the current compilation unit and rely on smart linker to collapse duplicated code? Rely on explicit template instantiation?

Automatic Template Instanciation: AT&T C++/Sun CC Generate external functions If the specification of a class is in toto.H, the compiler looks for its implementation in toto.C by default File toto.C must also be in the #include search path The compiler generates code in a subdirectory (ptrepository, Templates.DB...) and handles chronological dependency with the source The compiler finds which template are to be instantiated by simulating link edition (unresolved symbols)
(1)

Automatic Template Instantiation: AT&T C++/Sun CC
source-files (except template) #include .H files (template) .C files (template)
(2)
CC (compiler)
Some references still unsolved
Source generation
Object-files (except template)
Source-files (template)
Simulated link edition All references solved Link edition
CC (compiler)
Object-files (template)
3-64

Automatic Template Instantiation: GNU gcc 2.9x gcc requires the full definition of the template It does not yet support export Thus it is necessary to put everything into the .H file or to include the .C into the .H On systems supporting ELF binaries (Solaris, Linux...) gcc generate the instantiated template code in each compilation unit and relies on its own linker to collapse the duplicated code
The object files may become huge! But the resulting executable is smaller (than the sum of object files)

Summary New keywords Miscellaneous extensions (goodies) Scope of loop indexes; variables in conditions Pointer to class members Name packaging (namespace, using)
3-66

Keywords
and and_eq asm auto bitand bitor bool break case catch char class compl const const_cast continue default delete do double dynamic_cast else enum explicit extern false float for friend goto if inline int long mutable namespace new not not_eq operator or or_eq private protected public register reinterpret_cast return short signed sizeof static static_cast struct switch template this throw true try typedef typeid typename union unsigned using virtual void volatile wchar_t while xor xor_eq
Legend:
break class throw bitand
already in ANSI C introduced in C++ (3.0) introduced by ANSI C++ introduced by ANSI C++ as an alternative denotation for some operators (same sort of brain damage as trigraphs!)
3-67

Really Miscellaneous Support for European and extended characters Booleans (bool, true, false) Overloading resolution takes enum into account Constructors or conversion operators with explicit conversion (explicit)
class A { public: explicit explicit ... }; A a = 3; // a = 5; // A(int); operator double() const;
(1)
OK, invoke constructor implicit user conversion A(5) forbidden

3-68

Really Miscellaneous Non constant members even in constant objects (mutable) Allow to reduce the number of casts removing const? Similar to const and volatile (but only applicable to class members) Direct initialization of const static integer members
class Table { const static int N = 10; int t[N]; };
(2)
// OK // OK
3-69

Really Miscellaneous Relaxing the return type of a function overridden (redefined) in a derived class (covariance)
class A { ... A& f(int, double); }; class B : public A{ ... B& f(int, double); };
(3)
// OK: redefines f
3-70

Really Miscellaneous Forward declaration of nested classes
class List { class Cell; Cell *first; ... }; // OK, defined later // OK
(4)
class List::Cell { ... };
3-71

Scope of Loop Indexes; Variables in Conditions If the loop index is declared in the for clause, its scope is limited to the loop body (including the for clause)
for (int i = 0; i < N; i++) if (t[i] == x) break; t[i]++; // NO: i is unknown here
In the same spirit, variables may be defined in conditions (in if or in loops)

if (int c = ...) {// c is only known here} while (int c = ...) {// c is only known here}

Motivation Define a function taking a member-function as parameter
class Window { int width, height; int cursor_x, cursor_y; public: void up(); void down(); void right(); void left(); void repeat( ??? , int n); };
(1)

Motivation What is the type of up, down... ? Certainly not void (*)() because class membership must be taken into account Pointer to a member-function of class Window with no parameter nor result
void (Window::*)()
(2)
3-74

Utilization of Pointers to Member-Functions Value
typedef void (Window::*Movements)(); Movements tab[] = {&Window::up, &Window::down, ...};
Through a pointer
void Window::repeat(void (Window::*op)(), int n) { for (int i = 0; i < n; ++i) (this->*op)(); }
Through an instance or a reference

void afunction(void (WIndow::*op)(), Window& w) { (w.*op)(); }

Pointers to Data Members
class A { ... int x; int y; ... };
int A::*pmi = &A::x; A a, *pa = &a; ... a.*pmi = 12; // a.x = 12 pmi = &A::y; pa->*pmi = 27: // pa->y = 17
pointers to data members are sorts of portable offsets


Standard Conversions of Pointers to Members A pointer to a base class member can be implicity converted into a pointer to a derived class member
class A { int x; }; class B : public A { ... };
int A::*pma = &A::X B b; b.*pma = 12; // OK: b.x b.A::x = 12
Note that this conversion goes into the direction opposite to the other inheritance conversions

Motivation Avoid name collisions due to an unique global name space when merging programs when using several libraries... Classes were already name spaces Explicit qualification (::) was required outside the class, though
3-78

Definition
namespace My_Lib { class List {...}; void f(int, double); int f(char); ... }
A namespace is open : it can be extended simply by opening a new namespace clause with the same name The anonymous namespace is guaranteed collision-free Name spaces can be nested

Utilization
My_Lib::List l; My_Lib::f(3, 12.5); int i = My_Lib::f('a'); using My_Lib::f; f(3, 12.5); int i = f('a'); // using declaration
using namespace My_Lib; // using directive List l; f(3, 12.5); int i = f('a');

Synonyms
namespace Ecole_Superieure_en_Sciences_Informatiques { ... }
namespace ESSI = Ecole_Superieure_en_Sciences_Informatiques;
3-81

Backwards Compatibility (1)
Standard ISO C++ library are in a predefined name space (std) Standard ANSI C .h files are also part of ISO C++, but their name is prefixed by c (e.g., <cstdio.h>, <cstring.h>, <cctypes.h>...) All standard ANSI C functions are part of the std namespace (prinft, sin...)
3-82

Backwards Compatibility Standard C++ .h files (e.g., <iostream.h>, <string.h>) are terminated with a using std directive The files with the same names but without extension .h (e.g., <iostream>, <string>...) do not include this using directive Unary operator :: allows access to a particular name space, the global space BEWARE: this global space is different from std, hence some risks of incompatibility with previous programs
(2)

Class as a Namespace Classes are namespace Directive using namespace is forbidden in a class Declaration using for an inherited member allow to locally import the member or to adjust its access control level (1)
3-84

Class as a Namespace
class A {public: void f(char);}; class B : public A { public: using A::f; // import A::f void f(int); // overloading, not hiding } class C : private A{ public: using A::f; // makes A::f public in C }; // the previous notation // A::f is now obsolete
(2)
3-85
References
[1]
Andrei ALEXANDRESCU Modern C++ Design: Generic Programming and Design Patterns Applied
[6]
James O. COPLIEN Advanced C++: Programming Style and Idioms
Addisson Wesley, 2001

A fascinating book about template programming in C++. Certainly difficult but worht the effort for would-be C++ experts. [2] ANSI Technical Committee X3J11 Rationale for the ANSI C Programming Language [7]
Addison Wesley, 1992

Each language has its specific constructs, its idioms. This book describe some of the most important C++ idioms. Indispensible for mastering C++. James O. COPLIEN Multi-Paradigm Design for C++
Silicon Press, 1990.

Why is ANSI C as it is and not better? [3] John BARNES Programming in ADA [8]

C++ as a multi-paradigm language (that is supporting several programming styles). Brad J. COX Object-oriented Programming: an Evolutionary Approach
(4th Edition), Addison Wesley, 1995

A classical book on ADA. Also includes ADA 95. [4] Grady BOOCH Object-Oriented Analysis and Design with Applications [9]

The book on Objective C.
(2nd Edition), The Benjamin/Cummings Publishing Co, 1994.

Grady BOOCH wrote several reference text books on object-orientation. This is one of them. The examples are given in C++. [5] Don BULKA, David MAYHEW Efficient C++: Performance Programming Techniques [10]
Margaret ELLIS, Bjarne STROUSTRUP The Annotated C++ Reference Manual

THe reference on C++ version 2.1, but also the basis for tLa rfrence she ANSI/ISO Committee work. Somewhat obsolete now. Erich GAMMA, Richard HELM, Ralph JOHNSON, John VLISSIDES Design Patterns: Elements of Reusable Object-Oriented Software
Adison-Wesley, 2000
Make C++ run fast, avoid the inefficiency pitfalls.

The book on Design Patterns. Profound and innovative. A must read.
B-1
Programmation avance en C++

[11] Adele GOLDBERG, David ROBSON SmallTalk-80: the Language [18] Andrew KOENIG, Barbara MOO Ruminations on C++
Bibliographie commente

The reference on SmallTalk-80 (version 2). [12] Mats HENRICSON, Erik NYQUIST Industrial Strength C++ [19]

Programming quiz, idioms, advices. Instructive with humour. Stanley B. LIPPMAN, Josee LAJOIE C++ Primer
Prentice Hall, 1997

The practice and coding conventions in C++ within an important swedish telecommunication company. [20] [13] International Standard for Information Systems: Programming Language C++
(3rd Edition), Addison Wesley, 1998

An excellent introduction to C++ programming. Tony MASON, Doug BROWN lex and yacc
ISO/IEC 14882:1998(E)
The standard itself. Not really a tutorial! [14] Nicolai M. JOSUTTIS The C++ Standard Library [21]
OReilly Associates, Inc, 1991.

All you want to know about Lex and Yacc, the UNIX lexical and syntactic analyzers generators. Bertrand MEYER Object-oriented Software Construction

An excellent book about the C++ STL. [15] Brian W. KERNIGHAN, Rob PIKE The UNIX Programming Environment [22]
Prentice Hall International Series in Computer Science, 1988

Beyond a presentation of EIFFEL, the ideas of Bertrand MEYER about objectoriented programming and design.. Another must read. Bertrand MEYER EIFFEL: the Language
Prentice Hall Software Series, 1984

A classic book on the UNIX environment and the small is beautiful approach. [16] Brian W. KERNIGHAN, Denis M. RITCHIE The C Programming Language (ANSI C) [23]
Prentice Hall Object-Oriented Series, 1992.

The reference on the EIFFEL language. Presentation of high quality. Scott MEYERS Effective C++: 50 Specific Ways to Improve your Programs and Designs
(2nd Edition), Prentice Hall Software Series, 1988

The most recent edition of a book which has set up a reference on the C language, since 1978. Essentially the same book, but updated to ANSI C. [24] [17] Bjrn KIRKERUD Object-oriented Programming with SIMULA
Addison Wesley Professional Computer Series, 1992.

50 advices (and sometimes recipes) for C++ programmers. Very instructive. Scott MEYERS More Effective C++: 35 New Ways to Improve your Programs and Designs

PFor an introduction to SIMULA, the first object-oriented language.

The sequel of the previous book. Same quality.
B-2
Programmation avance en C++

[25] Scott MEYERS Effective C++ CD: 85 Specific Ways to Improve your Programs and Designs [31] Peter WEGNER The Object-Oriented Classification Paradigm
Bibliographie commente

The two previous books in CD ROM form. Very handy to browse the various advices and examples.. [26] Greg NELSON System Programming with Modula-3
in Research Directions in Object-Oriented Programming, pp 479-560, Bruce Shiver et Peter Wegner (diteurs), The MIT Press, 1988.
An attempt to model the object-oriented concepts by a prestigious author. Always instructive.
Prentice hall Series in Innovative Technology, 1991

A good introduction to Modula-3, another object-oriented language. [27] Bjarne STROUSTRUP The C++ Programming Language
(3rd Edition), Addison Wesley, 1997

The books of Bjarne on C++ have improved with time. This third edition is really excellent, with a complete coverage of C++ and the Standard Template Library, and many examples. [28] Bjarne STROUSTRUP The Design and Evolution of C++

Why is C++ as it is. The stoy about the definition of the language and its standardization process. How the features of C++ were introduced into the language? And, at least as interesting, why some features were rejected. A fascinating, one of a kind, book. Before criticizing C++, please read it! [29] Herb SUTTER Exceptional C++

All you wanted to know (and even more) about C++ exceptions, their use, their idoms, their semantics, their pitfalls... [30] Herb SUTTER More Exceptional C++

All you dear not ask about C++ exceptions, their use, their idoms, their semantics, their pitfalls...
B-3

Advanced C++

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced C++

Uploaded by

Copyright:

Available Formats

Version 3.

Advanced C++ Programming

1996-2003 Jean-Paul R IGAULT

Advanced C++ Programming

1996-2003 Jean-Paul R IGAULT Version 3.1

Advanced C++ Programming

Contents of the Course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .0-2

References for this Course

Indispensable Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6

2.Fundamental Mechanisms in C++

Objects and Types

The C++ Class

Advanced C++ Programming

A Reuse Unit through Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24

Objects Handling Creating, deleting, and initializing objects

Creation, Utilization, and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25

3.Advanced Mechanisms and ANSI Extensions

Run Time Type Information (RTTI)

1996-2003 Jean-Paul R IGAULT Version 3.1

Advanced C++ Programming

Conversions and Virtual Base Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38

Generic Functions and Classes (template)

Miscellaneous ANSI C++ Extensions

Pointers to Class Members

Name Packaging (namespace)

1996-2003 Jean-Paul R IGAULT Version 3.1

Advanced C++ Programming

1996-2003 Jean-Paul R IGAULT Version 3.1

Advanced C++ Programming

1996, 2003 Jean-Paul RIGAULT Version 3.1

Advanced C++ Programming

Advanced C++ Programming

1996, 2003 Jean-Paul RIGAULT Version 3.1

Advanced C++ Programming

1996, 2003 Jean-Paul RIGAULT Version 3.1

Advanced C++ Programming

1996, 2003 Jean-Paul RIGAULT Version 3.1

Advanced C++ Programming

Advanced C++ Programming

Advanced C++ Programming

Advanced C++ Programming

References for this Course

1996, 2003 Jean-Paul RIGAULT Version 3.1

Advanced C++ Programming

References for this Course

Advanced C++ Programming

2. Fundamental Mechanisms in C++

1996, 2003 Jean-Paul RIGAULT Version 3.1

Advanced C++ Programming

2. Fundamental Mechanisms in C++

Fundamental Mechanisms in C++

1996, 2003 Jean-Paul RIGAULT Version 3.1

Advanced C++ Programming

2. Fundamental Mechanisms in C++

Objects and Types

Advanced C++ Programming

2. Fundamental Mechanisms in C++

Objects and Types

Advanced C++ Programming

2. Fundamental Mechanisms in C++

Objects and Types

1996, 2003 Jean-Paul RIGAULT Version 3.1

Advanced C++ Programming