1.2 Overall Structure of the Book

Ru-Brd

1.2 Overall Structure of the Book

Our goal is to provide the information necessary for starting to use templates and benefit from their power, as well as to provide information that will enable experienced programmers to push the limits of the state-of-the-art. To achieve this, we decided to organize our text in parts :

Part I introduces the basic concepts underlying templates. It is written in a tutorial style.
Part II presents the language details and is a handy reference to template- related constructs.
Part III explains fundamental design techniques supported by C++ templates. They range from near-trivial ideas to sophisticated idioms that may not have been published elsewhere.
Part IV builds on the previous two parts and adds a discussion of various popular applications for templates.

Each of these parts consists of several chapters. In addition, we provide a few appendixes that cover material not exclusively related to templates (for example, an overview of overload resolution in C++).

The chapters of Part I are meant to be read in sequence. For example, Chapter 3 builds on the material covered in Chapter 2. In the other parts, however, the connection between chapters is considerably looser. For example, it would be entirely natural to read the chapter about functors (Chapter 22) before the chapter about smart pointers (Chapter 20).

Last, we provide a rather complete index that encourages additional ways to read this book out of sequence.

Ru-Brd

1.3 How to Read This Book

If you are a C++ programmer who wants to learn or review the concepts of templates, carefully read Part I, The Basics. Even if you're quite familiar with templates already, it may help to skim through this part quickly to familiarize yourself with the style and terminology that we use. This part also covers some of the logistical aspects of organizing your source code when it contains templates.

Depending on your preferred learning method, you may decide to absorb the many details of templates in Part II, or instead you could read about practical coding techniques in Part III (and refer back to Part II for the more subtle language issues). The latter approach is probably particularly useful if you bought this book with concrete day-to-day challenges in mind. Part IV is somewhat similar to Part III, but the emphasis is on understanding how templates can contribute to specific applications rather than design techniques. It is therefore probably best to familiarize yourself with the topics of Part III before delving into Part IV.

The appendixes contain much useful information that is often referred to in the main text. We have also tried to make them interesting in their own right.

In our experience, the best way to learn something new is to look at examples. Therefore, you'll find a lot of examples throughout the book. Some are just a few lines of code illustrating an abstract concept, whereas others are complete programs that provide a concrete application of the material. The latter kind of examples will be introduced by a C++ comment describing the file containing the program code. You can find these files at the Web site of this book at http://www.josuttis.com/tmplbook/.

Ru-Brd

1.4 Some Remarks About Programming Style

C++ programmers use different programming styles, and so do we: The usual questions about where to put whitespace, delimiters (braces, parentheses), and so forth came up. We tried to be consistent in general, although we occasionally make concessions to the topic at hand. For example, in tutorial sections we may prefer generous use of whitespace and concrete names to help visualize code, whereas in more advanced discussions a more compact style could be more appropriate.

We do want to draw your attention to one slightly uncommon decision regarding the declaration of types, parameters, and variables . Clearly, several styles are possible:

void foo (const int &x); 
void foo (const int& x); 
void foo (int const &x); 
void foo (int const& x);

Although it is a bit less common, we decided to use the order int const rather than const int for "constant integer." We have two reasons for this. First, it provides for an easier answer to the question, " What is constant?" It's always what is in front of the const qualifier. Indeed, although

const int N = 100;

is equivalent to

int const N = 100;

there is no equivalent form for

int* const bookmark;

// the pointer cannot change, but the


// value pointed to can change

that would place the const qualifier before the pointer operator * . In this example, it is the pointer itself that is constant, not the int to which it points.

Our second reason has to do with a syntactical substitution principle that is very common when dealing with templates. Consider the following two type definitions ^[1] :

^[1] Note that in C++ a type definition defines a "type alias" rather than a new type. For example:
typedef int Length;

// define

Length

as an alias for

int 
int i = 42; 
Lengthl = 88; 
i = l;

// OK

l = i;

// OK

typedef char* CHARS; 
typedef CHARS const CPTR;

// constant pointer to

char

s

The meaning of the second declaration is preserved when we textually replace CHARS with what it stands for:

typedef char* const CPTR;

// constant pointer to

char

s

However, if we write const before the type it qualifies, this principle doesn't apply. Indeed, consider the alternative to our first two type definitions presented earlier:

typedef char* CHARS; 
typedef const CHARS CPTR;

// constant pointer to

char

s

Textually replacing CHARS results in a type with a different meaning:

typedef const char* CPTR;

// pointer to constant

char

s

The same observation applies to the volatile specifier , of course.

Regarding whitespaces, we decided to put the space between the ampersand and the parameter name :

void foo (int const& x);

By doing this, we emphasize the separation between the parameter type and the parameter name. This is admittedly more confusing for declarations such as

char* a, b;

where, according to the rules inherited from C, a is a pointer but b is an ordinary char . To avoid such confusion, we simply avoid declaring multiple entities in this way.

This is not a book about the C++ standard library, but we do make use of that library in some of our examples. In general, we use the C++-specific headers (for example, < iostream > rather than <stdio.h> ). The exception is <stddef.h> . We use it instead of <cstddef> and therefore do not qualify size_t and ptrdiff_t with the std:: prefix because this is still more portable and there is no advantage in using std::size_t instead of size_t .