What Is C++? C++ is a general-purpose, platform-neutral programming language that supports object-oriented programming and other useful programming paradigms, including procedural programming, object-based programming, generic programming, and functional programming. C++ is viewed as a superset of C, and thus offers backward compatibility with this language. This reliance on C provides important benefits:
• • • •
Reuse of legacy C code in new C++ programs Efficiency Platform neutrality Relatively quick migration from C to C++
Yet it also incurs certain complexities and ailments such as manual memory management, pointers, unchecked array bounds, and a cryptic declarator syntax, as described in the following sections. As opposed to many other programming languages, C++ doesn't have versions. Rather, it has an International ANSI/ISO Standard, ratified in 1998, that defines the core language, its standard libraries, and implementation requirements. The C++ Standard is treated as a skeleton on which vendors might add their own platform-specific extensions, mostly by means of code libraries. However, it's possible to develop largescale applications using pure standard C++, thereby ensuring code portability and easier maintenance. The primary reason for selecting C++ is its support of object-oriented programming. Yet even as a procedural programming language, C++ is considered an improvement over ANSI C in several aspects. C programmers who prefer for various reasons not to switch to object-oriented programming can still benefit from the migration to C++ because of its tighter type-safety, strongly typed pointers, improved memory management, and many other features that make a programmer's life easier. Let's look at some of these improvements more closely:
•
Improved memory management. In C, you have to call library functions to allocate storage dynamically and release it afterwards. But C++ treats dynamically allocated objects as first-class citizens: it uses the keywords new and delete to allocate and deallocate objects dynamically. User-defined types are treated as built-in types. For example, a struct or a union's name can be used directly in declarations and definitions just as a built-in type:
• •
struct Date
•
{
•
int day;
•
int month;
•
int year;
•
};
• •
Date d; //In C, 'struct' is required before Date void func(Date *pdate); //ditto
•
Pass-by-reference. C has two types of argument passing: by address and by value. C++ defines a third argument-passing mechanism: passing by reference. When you pass an argument by reference, the callee gets an alias of the original object and can modify it. In fact, references are rather similar to pointers in their semantics; they're efficient because the callee doesn't get a copy of the original variable, but rather a handle that's bound to the original object. Syntactically, however, references look like variables that are passed by value. Here's an example:
•
Date date;
•
void func(Date &date_ref); //func takes Date by reference func(date); // date is passed by reference, not by value
•
Default argument values. C++ allows you to declare functions that take default argument values. When the function call doesn't provide such an argument, the compiler automatically inserts its respective default value into the function call. For example:
•
void authorize(const string & username, bool log=true); authorize(user); // equivalent to: authorize(user, true); In the function call above, the programmer didn't provide the second argument. Because this argument has a default value, the compiler silently inserted true as a second argument.
•
Mandatory function prototypes. In classic C, functions could be called without being previously declared. In C++, you must either declare or define a function before calling it. This way, the compiler can check the type and number of each argument. Without mandatory prototypes, passing arguments by reference or using default argument values wouldn't be possible because the compiler must replace the arguments with their references or add the default values as specified in the prototype.
A well-formed C++ program must contain a main() function and a pair of matching braces:
int main() {} Though perfectly valid, this program doesn't really do anything. To get a taste of C++, let's look at a more famous example:
#include
int main() { std::cout<<"hello world!"<
#include int main() { printf("hello world!\n"); } Let's take a closer look at the C++ example. The first line is a preprocessor directive that #includes the standard header in the program's source file:
#include contains the declarations and definitions of the standard C++ I/O routines and classes. Taking after C, the creators of C++ decided to implement I/O support by means of a code library rather than a built-in keyword. The following line contains the main() function. The program consists of a single line:
std::cout<<"hello world!"<
• • •
std::cout is the qualified name of the standard output stream object, cout. This object is automatically created whenever you #include . The overloaded insertion operator << comes next. It takes an argument and passes it on to cout. In this case, the argument is a literal string that we want to print on the screen. The second argument, std::endl, is a manipulator that appends the newline character after the string and forces buffer flushing.
As trivial as this program seems, it exposes some of the most important features of C++. For starters, C++ is an object-oriented language. Therefore, it uses objects rather than functions to perform I/O. Secondly, the standard libraries of C++, including , are declared in the namespace std (std stands for standard. An exhaustive discussion about namespaces is available in the "Namespaces" section.). Thus, instead of declaring standard functions, classes, and objects globally, C++ declares them in a dedicated namespace—thereby reducing the chances of clashing with user code and third-party libraries that happen to use the same names.
Overloading The operator << is particularly interesting. It behaves as a function that takes an argument, yet it looks like the built-in left-shift operator. In reality, it's an overloaded operator. Operator overloading is another fundamental concept of C++. An overloaded operator is a function whose name is an operator rather than a string. You can override almost all the built-in operators of C++ (+, *, >, and so on) this way. Operator overloading may sound revolutionary and even dangerous at first; after all, if programmers are free to override the meaning of built-in operators, what's to stop them from defining operator + as the subtraction operator? Rest assured. C++ imposes certain restrictions on operator overloading. The combination of these restrictions and good object-oriented practices guarantee that this feature makes code uniform and intuitive. Consider the notion of a string. In C, assigning strings with the = operator is not allowed. By contrast, the C++ std::string class overloads this operator and enables you to perform direct assignments of strings. For example:
std::string s; s= "please fasten your seatbelt"; Without operator overloading, the snippet would look like this:
std::string s; s.assign("please fasten your seatbelt"); When dealing with numeric libraries, the ability to overload operators (such as ==, +,and -) for user-defined types is particularly useful. Overloading in C++ isn't limited to operators. You can also overload functions by giving two or more functions an identical name. The overloaded functions are distinguished by their parameter list. For example, a function that opens a file may have three different overloaded versions:
int file_open(int descriptor); // #1 int file_open(const char *pathname); // #2 int file_open(const string & pathname); // #3 The compiler determines which of the three overloaded versions is to be called by examining the function's argument. For example:
std::string file="modem.log"; file_open(file); // call file_open() #3
The resolution is static, meaning that it takes place at compile time. There are two advantages in static overloading resolution: The compiler is able to detect incorrect arguments, and there's no performance overhead. Like C, C++ supports the "separate compilation" model, whereby a program may consist of individual source files that are compiled separately. These files are translated into object files that are later linked to produce a single executable file. Unlike several modern programming languages, however, a C++ source file is compiled into native machine code, not bytecodes or any other form of intermediary code that needs to be translated further at runtime. The advantage is efficiency—the compiled code is optimized for the target hardware. The tradeoff is the lack of binary compatibility—the compiled code is platform dependent.
Support for Object-Oriented Programming Although C++ didn't define object-oriented programming, it was the first widely used programming language that supported this paradigm. Undoubtedly, you've heard of object-oriented programming before. But what does it really mean? An object-oriented programming language must support these features:
• • • • • •
Abstract datatyping Information hiding Encapsulation Dynamic binding Polymorphism Inheritance
The section "Object-Oriented Programming and Design Principles" discusses these concepts in detail. However, suffice it to say that C++ supports all of these criteria as well as many others. As stated previously, C++ supports many useful programming paradigms in addition to object orientation— such as generic programming. Generic programming enables programmers to write algorithms and classes that are type-independent. The programmer writes a single code mold called a template, from which the compiler synthesizes type-specific instances. For example, a generic swap algorithm may be defined as follows:
template void swap( T & t1, T & t2) { T temp=t1; t1=t2; t2=temp; } int n=5, m=10; swap(n,m); The compiler treats the template function above as a mold from which it generates an instance of swap() that applies to type int. In other words, it replaces the symbol T with the concrete type int. This is quite similar to the way macros work, except that in this case the compiler rather than the preprocessor expands the template. Consequently, it's able to detect type mismatches and other violations of syntax rules. Not very surprisingly, the Standard Library has a swap() algorithm, so you don't have to implement it by yourself. In fact, the Standard Library contains dozens of useful generic algorithms that count, sort, merge, replace, splice, and do many other useful operations. In addition to function templates, C++ supports class templates. A class template serves as a mold from which other classes are instantiated. Class templates are widely used in the Standard Library as generic containers—list, vector, stack, and so on. A rich set of generic algorithms that operate on generic containers is one of the main strengths of C++. "A Tour of C++" is a sample chapter from The C++ Programming Language, Special Edition (AddisonWesley, 2000, 0201700735), by Bjarne Stroustrup. This article is an excellent introduction to C++, its standard library, and the various programming paradigms it supports. Stroustrup uses real-world examples
to demonstrate the differences between the design and implementation techniques used in each paradigm while exhibiting all the niceties of C++: its core features as well as its rich Standard Library. "Interview with C++ Expert Herb Sutter." In this interview, C++ guru Herb Sutter shares his thoughts on realworld programming, favorite teaching methods, and maintaining balance in a busy life. This interview isn't limited to programming techniques, but rather gives a glimpse into Sutter's philosophy of life and professional ethics. "Generic Programming and the C++ Standard Library" is a sample chapter from More Exceptional C++: 40 New Engineering Puzzles, Programming Problems, and Solutions (Addison-Wesley, 2001, ISBN 020170434X), by Herb Sutter. This article shows some of the power and flexibility of the C++ standard library. Prior experience with the language is assumed, so this article is ideal for the C++ programmer who want to learn how to use STL (short for Standard Template Library) and understand its design concepts. (Preview this book on Safari) The C++ Programming Language, Special Edition (Addison-Wesley, 2000, 0201700735), by Bjarne Stroustrup, is undoubtedly the best C++ book you can find today. Written by the creator of the language, the book covers in detail every aspect of the language. Stroustrup has always used real-world examples and his numerous years of experience in the software development field are well-reflected in every paragraph. Unlike most other C++ books that merely teach programming techniques, this book contains dozens of tips and practical pieces of advice from a world-renowned authority. Certainly, a must-have for every serious C++ programmer. C++ Primer (Addison-Wesley, 1998, ISBN 0201824701), by Stanley B. Lippman and Josée LaJoie, is a wellwritten C++ primer. Both authors are renowned C++ experts (LaJoie was IBM's representative to the ANSI standardization committee). The book excels in its coverage of C++. The authors carefully explain not just how, but why things are the way they are in C++. (Preview this book on Safari) The ANSI/ISO Professional Programmer's Handbook (Que, 1999, ISBN 0789720221), by Danny Kalev, discusses the changes that were introduced to the C++ standard in the late 1990s, explains the rationale behind them, and contrasts them with the pre-standard conventions and specifications. This book is primarily aimed at intermediate-to-advanced programmers who aren't fully aware of the latest changes in the language's specifications, including namespaces, RTTI, new cast operators, bool, covariant return, standard header names, and many other tidbits. The book contains extensive code samples, all of which are fully ANSI/ISO–compliant.
Special Member Functions: Constructors, Destructors, and the Assignment Operator Objects are the fundamental unit of abstraction in object-oriented programming. In a broad sense, an object is a region of memory storage. Class objects have properties that are determined when the object is created. Conceptually, every class object has four special member functions: default constructor, copy constructor, assignment operator, and destructor. If these members are not explicitly declared by the programmer, the implementation implicitly declares them. This section surveys the semantics of the special member functions and their roles in class design and implementation.
Assignment Operator An assignment operator assigns to its object another object. For example:
std::string s1="hello" std::string s2; s2=s1; If there's no user-defined assignment operator for a class, C++ implicitly declares one. An implicitly declared assignment operator has the following form:
C& C::operator=(const C&);
An assignment operator is said to be trivial if it's implicitly declared, if its class has no virtual member functions or virtual base classes, and if its direct base classes and embedded objects have a trivial assignment operator.
Operator Overloading Object-oriented (OO) programming languages treat user-defined types as first-class citizens. One of the manifestations of this principle is that programmers can extend the semantics of built-in operators to support user-defined types as if they were built-in types. Such an extension overloads rather than overrides the predefined meaning of an operator. NOTE C++ requires at least one of the operands of an overloaded operator to be a user-defined type. Although you can use ordinary functions for the same purpose, operator overloading provides a uniform notational convention that's clearer than the ordinary function call syntax. Consider the following example:
Monday < Tuesday; //overloaded < Greater_than(Monday, Tuesday); Clearly, the use of an overloaded < operator is a better choice. The capacity to redefine the meaning of a built-in operator in C++ was a source of criticism. People (mostly C programmers making the migration to C++) felt that overloading an operator was as dangerous as enabling the programmer to add, remove, or change keywords of the language. Still, notwithstanding the potential Tower of Babel that might arise as a result, operator overloading is one of the most fundamental features of C++ and is mandatory in generic programming, as the following sections will show. Today, even languages that tried to do without operator overloading are in the process of adding this feature. An overloaded operator is merely a function whose name is an operator preceded by the keyword operator. The following code listing defines an overloaded version of operator < that compares two Book objects and returns the one with the lower ISBN (for example, to sort a book collection by ISBN):
class Book { private: long ISBN; public: //... long get_ISBN() const { return ISBN;} };
//overloaded version of < bool operator < (const Book& b1, const Book& b2) { return b1.get_ISBN() < b2.get_ISBN(); }
Operator Overloading Guidelines When you're overloading an operator to support a user-defined type, it's recommended that you adhere to the basic semantics of the corresponding built-in operator. In other words, an overloaded operator has the same side effects on its operands and manifests the same interface as does the corresponding built-in operator. Most of the overloaded operators can be declared either as class member functions or as external functions. In the following example, the operator == is overloaded as a non-static class member:
class Date { private: int day; int month; int year; public: bool operator == (const Date & d ); // 1: member function }; Alternatively, it can be declared as a friend function:
// overloading == as an external function class Date; bool operator ==( const Date & d1, const Date& d2); class Date { private: int day; int month; int year; public: friend bool operator ==( const Date & d1, const Date& d2); }; However, the operators [], (), =, and -> can only be declared as non-static member functions; this ensures that their first operand is an lvalue. When you overload an operator, adhere to the interface of its built-in counterpart. The interface of an operator consists of the number of operands to which it applies, whether any of these operands can be altered by the operator, and the return value of that operator. For example, consider operator ==. Its built-in version is applicable to a wide variety of fundamental types, including int, bool, float, and char, and to pointers. In all these cases, the built-in == operator tests its left and right operands for equality and returns a result of type bool. Note that == doesn't modify any of its operands and that their order is
immaterial. To implement all these features in an overloaded ==, define it as a friend function rather than a member function. The following example shows the difference between these two options:
class Date { private: int day; int month; int year; public: Date(); bool operator == (const Date & d) const; // 1 asymmetrical //2 symmetrical friend bool operator ==(const Date& d1, const Date& d2); };
bool operator ==(const Date& d1, const Date& d2); The member overloaded operator == (1) is inconsistent with the built-in operator == because its arguments have different types. The compiler transforms the member operator == into the following:
bool Date::operator == (const Date *const, const Date&) const; The first argument is the implicit this pointer. The second argument is a reference to const Date. By contrast, the friend version takes two arguments of the same type. There are practical implications to favoring the friend version over the member function. STL algorithms rely on a symmetrical version of the overloaded operator ==. For example, containers that store objects that don't have symmetrical operator == cannot be sorted. Another example, built-in operator +=, which also takes two operands, modifies its left operand but leaves the right operand unchanged. The interface of an overloaded += needs to reflect the fact that it modifies its object but not its right operand. This is reflected by the declaration of the function parameter as const, whereas the function itself is a non-const member function:
class Date { ... public: Date(); //built-in += changes its left operand but not its right one //the same behavior is maintained here Date & operator += (const Date & d); };
To conclude, it can be said that every overloaded operator must implement the same interface of its built-in counterpart. As previously noted, an overloaded operator is a function that's declared with the operator keyword, immediately followed by an operator ID. An operator ID can be one of the following:
new delete
new[]
+
-
*
/
%
!
=
<
>
+=
-=
*=
^
delete[] &
|
~ /=
%=
^=
&=
|=
<<
>>
>>= <<= ==
<=
>=
&&
||
++
--
()
[]
,
!=
->* ->
In addition, the following operators can be overloaded both in their unary and binary forms:
+
-
*
&
Derived classes inherit the overloaded operators of their base classes in the same manner as ordinary member functions are inherited (the assignment operator is an exception). An overloaded operator must take at least one argument of a user-defined type. This rule ensures that users cannot alter the meaning of expressions that contain only fundamental types. For example:
int i,j,k; k = i + j; //always uses built-in = and + An overloaded operator extends a built-in one, so you cannot introduce new operators into the language. Neither the precedence nor the number of arguments of an operator can be altered. For example, an overloaded && must have exactly two arguments, as does the built-in && operator. In addition, you can't change the precedence of an operator. A sequence of two or more overloaded operators, t2
• • • •
Direct member access (.) Deference pointer to class member (.*) Scope resolution (::)o Size of (sizeof)
The conditional operator (?:) also cannot be overloaded.l Additionally, the new typecast operators: static_cast<>, dynamic_cast<>, reinterpret_cast<>, and const_cast<>, and the # and ## preprocessor tokens cannot be overloaded. Returning Objects by Value
Large objects are usually passed to or returned from a function by reference or by their addresses. In a few circumstances, however, the best choice is to return an object by value. Operator + is an example of this situation. It has to return a result object, but it cannot modify any of its operands. The seemingly natural choice is to allocate the result object dynamically and return its address. But this is not such a good idea. Dynamic memory allocation is significantly slower than local storage. It also might fail and throw an exception. Worse yet, this solution is error-prone because it's unclear who is responsible for deleting this object. Returning a reference to a static object might seem tempting:
class Year { private: int year; public: Year(int y = 0) : year(y) {} Year& operator + (const Year& other) const; //returns a reference to //a local static Year int getYear() const; void setYear(int y); };
Year& Year::operator + (const Year& other) const { static Year result; result = Year(this->getYear() + other.getYear() ); return result; } Alas, on each invocation of the overloaded operator, the same object is being modified and returned to the caller. Therefore, the safest and most efficient solution is to return the result object by value:
class Year { private: int year; public: Year(int y = 0) : year(y) {} //return Year object by value Year operator + (const Year& other) const; int getYear() const;
void setYear(int y); };
Year Year::operator + (const Year& other) const { return Year(this->getYear() + other.getYear() ); } Overloading and User-Defined Types Overloading isn't limited to classes. You can overload an operator for enum types as well. Here's an example:
#include using namespace std;
enum Days { Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday };
Days& operator++(Days& d, int) // postfix ++ { if (d == Sunday) return d = Monday; //rollover int temp = d; //convert to an int return d = static_cast (++temp); }
int main()
{ Days day = Monday; for (;;) //display days as integers { cout<< day <
//display Days in symbolic form ostream& operator<<(ostream& os, Days d) { switch(d) { case Monday: return os<<"Monday"; case Tuesday: return os<<"Tuesday"; case Wednesday: return os<<"Wednesday"; case Thursday: return os<<"Thursday"; case Friday: return os<<"Friday"; case Saturday: return os<<"Saturday"; case Sunday: return os<<"Sunday"; default:
return os<<"Unknown"; } }
Conversion Operators A conversion operator can be thought of as a user-defined typecasting operator; it converts its object to a different type in contexts that require that specific type. The conversion is done automatically. For example:
class Mystring { private: char *s; int size; public: Mystring(); //convert Mystring to a C-string operator const char * () {return s; } //... };
int n = strcmp(str, "Hello"); //OK, automatic conversion of str //to const char * Conversion operators differ from ordinary overloaded operators in two ways. First, a conversion operator has no return value (not even void). The return value is inferred from the operator's name. Secondly, a conversion operator takes no arguments. Conversion operators can convert their objects to any given type, fundamental and user-defined alike:
struct DateRep //legacy C code { char day; char month; short year; };
class Date // object-oriented wrapper { private: DateRep dr; public: // automatic conversion to DateRep operator DateRep () const { return dr;} };
// C-based communication API function extern "C" int transmit_date(DateRep);
int main() { Date d; //...use d
//transmit date object as a binary stream to a remote client int ret_stat = transmit_date(d); //using legacy communication API return 0; }
Constructor A constructor initializes an object. A default constructor is one that can be invoked without any arguments. If there is no user-declared constructor for a class, and if the class doesn't contain const or reference data members, C++ implicitly declares a default constructor for it. Such an implicitly declared default constructor performs the initialization operations needed to create an object of this type. Note, however, that these operations don't involve initialization of user-declared data members. For example:
class C { private: int n; char *p; public: virtual ~C() {} };
void f() { C obj; // 1 implicitly-defined constructor is invoked } C++ synthesized a constructor for class C because it contains a virtual member function. Upon construction, C++ initializes a hidden data member called the virtual pointer, which every polymorphic class has. This pointer holds the address of a dispatch table that contains all the virtual member functions' addresses for that class. The synthesized constructor doesn't initialize the data members n and p, nor does it allocate memory for the data pointed to by the latter. These data members have an indeterminate value once obj has been constructed. This is because the synthesized default constructor performs only the initialization operations that are required by the implementation—not the programmer—to construct an object. Other implementation-required operations that are performed by implicitly-defined constructors are the invocation of a base class constructor and the invocation of embedded object's constructor. However, C++ doesn't declare a constructor for a class if the programmer has defined one. For example:
class C { private: int n; char *p; public: C() : n(0), p(0) {} virtual ~C() {} }; C obj; // 1 user-defined constructor is invoked Now the data members of the object obj are initialized because the user-defined constructor was invoked to create it. This still leaves us with a mystery: The user-defined constructor only initializes the data members n and p. When did the initialization of the virtual pointer take place? Here's the answer: The compiler augments the user-defined constructor with additional code, which is inserted into the constructor's body before any user-written code, and performs the necessary initialization of the virtual pointer. Trivial Constructors As noted previously, compilers synthesize a default constructor for every class or struct, unless a constructor was already defined by the user. However, in certain conditions, such a synthesized constructor is redundant:
class Empty {}; struct Person { char name[20]; double salary; int age;
}; int main() { Empty e; Person p; p.age = 30; // public access allowed, no constructor needed return 0; } C++ can instantiate Empty and Person objects without a constructor. In such cases, the implicitly declared constructor is said to be trivial. The fact that a constructor is considered trivial means that neither the programmer nor the compiler generates code for it. We'll discuss this in greater detail shortly. Constructors of Built-in Types You might be surprised to hear this: Built-in types such as char, int, and float also have constructors. You can initialize a variable by explicitly invoking its default constructor:
char c = char(); int n = int (); return 0; This expression:
char c = char(); is equivalent to this one:
char c = char(0); Of course, it's possible to initialize a fundamental type with values other than 0:
float f = float (0.333); char c = char ('a'); int *pi= new int (10); float *pf = new float (0.333); Note that this form is just "syntactic sugar." It's interchangeable with the more widely used form:
char c = 'a'; float f = 0.333; Explicit Constructors Constructors have many peculiar characteristics. They don't have a name (and therefore can't be called directly, as opposed to ordinary member functions); they don't have a return value; and their address cannot be taken. Non-default constructors are even more odd. A constructor that takes a single argument operates as an implicit conversion operator by default. Today, I will explore this phenomenon in further detail and explain how to use the explicit qualifier to restrain constructors' behavior.
Constructor Categories In essence, constructors are what differentiates between a POD struct and a real object, as they automatically shape a raw chunk of memory into an object with a determinate state. A class may have several constructors (in this discussion, I'm referring to "plain constructors," not to copy constructors), each of which taking a different number of arguments. A constructor that may be called without any arguments is a default-constructor. A non-default constructor is one that takes one or more arguments. (The C++ literature provides no special name for this type of constructor, so I'm referring to it as a "non-default constructor.") Non-default constructors are further divided into two subcategories: those that take a single argument and thus operate as implicit conversion operators, and those that take multiple arguments. For example,
class Date { public: Date(); // default ctor; no arguments required //non-default ctors: Date(time_t t); // extracts date from a time_t value Date(int d, int m, int y); // }; The class Date has three constructors. The first one is a default constructor. The second one, which takes a single argument, operates as an implicit time_t to D conversion operator. As such, it will be invoked automatically in a context that requires a long to Date conversion (Remember that time_t is a synonym for long or a similar integral type). For example,
Date d=std::time(0);// invokes ctor # 2 to create d You're probably wondering how it works. Under the hood, the compiler transforms this code into something like this:
//pseudo C++ code time_t __value; __value = std::time(0); Date __temp(__value);//create a temporary Date object Date d = __temp; temp.C::~C(); //destroy temp In this example, the automatic conversion is intentional and useful. Yet, there are many cases in which an implicit conversion is undesirable, for example:
Date p=NULL; //actually meant 'Date *p=NULL'; compiles OK Can you see what's happening here? NULL is defines as 0 or 0L in C++. The compiler silently transformed the code above into:
//pseudo C++ code Date temp(0L);//create a temporary Date object Date d = temp; //assigned using operator =
temp.C::~C(); //destroy temp The explicit Keyword The problem here is that the implicit conversion (taking place behind the programmer's back) switches off the compiler's static type checking. Without this implicit conversion, the compiler would have complained about a type mismatch. C++ creators perceived this problem long ago. They decided to add a "patch" to the language in the form of the keyword explicit. Constructors declared explicit will refuse to perform such implicit conversions:
class Date { //... explicit Date(time_t t); // no implicit conversions }; Now, the previous examples will not compile:
Date d =std::time(0); //error, can't convert 'long' to 'Date' Date p=NULL; //also an error To convert a time_t or any other integral value to a Date object, you need to use an explicit conversion now:
Date d(std::time(0)); //OK Date d2= Date(std::time(0)); //same meaning as above Advice If you examine a code corpus, say the Standard Library, you will see that most of the constructors taking one argument are explicit. One therefore could argue that this should have been the default behavior of constructors, whereas constructors that permit implicit conversions should have been the exception. Put differently, instead of explicit, C++ creators should have introduced the keyword implicit and changed the semantics of constructors so that they didn't function as implicit conversion operators. However, this approach would have caused existing code to break. In some classes, for example std::complex and other mathematical classes, implicit conversions are rather useful. The C++ creators therefore decided to leave the original semantics constructors intact, while introducing a mechanism for disabling implicit conversions, when necessary. As a rule, every constructor that takes a single argument, including constructors that take multiple arguments with default values such as the following, should be explicit, unless you have a good reason to allow implicit conversions:
class File { public: //this ctor may be called with a single argument //it's therefore declared explicit: explicit File(const char *name, ios_base::openmode mode=ios_base::out,
long protection = 0666); }; Member Initialization Lists A constructor may include a member initialization (mem-initialization for short) list that initializes the object's data members. For example:
class Cellphone //1: initialization by mem-init { private: long number; bool on; public: Cellphone (long n, bool ison) : number(n), on(ison) {} }; The constructor of Cellphone can also be written as follows:
Cellphone (long n, bool ison) //2: initialization within ctor's body { number = n; on = ison; } There is no substantial difference between the two forms in this case because the compiler scans the meminitialization list and inserts its code into the constructor's body before any user-written code. Thus, the constructor in the first example is expanded by the compiler into the constructor in the second example. Nonetheless, the choice between using a mem-initialization list and initialization inside the constructor's body is significant in the following four cases:
•
Initialization of const members. For example:
•
class Allocator
•
{
•
private:
• • •
const int chunk_size; public: Allocator(int size) : chunk_size(size) {} };
•
Initialization of reference members. For example:
•
class Phone;
•
class Modem
•
{
•
private:
• •
Phone & line; public:
•
Modem(Phone & ln) : line(ln) {} };
•
Passing arguments to a constructor of a base class or an embedded object. For example:
•
class base
•
{
•
//...
•
public:
•
//no default ctor
•
base(int n1, char * t) {num1 = n1; text = t; }
•
};
•
class derived : public base
•
{
•
private:
• •
char *buf; public:
• •
//pass arguments to base constructor derived (int n, char * t) : base(n, t) { buf = (new char[100]);} };
•
Initialization of member objects. For example:
•
#include
•
using std::string;
•
class Website
•
{
•
private:
•
string URL
• •
unsigned int IP public:
•
Website()
•
{
•
URL = "";
•
IP = 0;
•
} };
In the first three cases, a mem-initialization list is mandatory because these initializations must be completed before the constructor's execution. Conceptually, initializations listed in a member-initialization list take place before the constructor executes. In the fourth case, the use of a mem-init list is optional. However, it can improve performance in certain cases because it eliminates unnecessary creation and subsequent destruction of objects that would occur if the initialization were performed inside the constrictor's body. Due to the performance difference between the two forms of initializing embedded objects, some programmers use mem-initialization exclusively. Note, however, that the order of the initialization list has to match the order of declarations within the class. This is because the compiler transforms the list so that it coincides with the order of the declaration of the class members, regardless of the order specified by the programmer. For example:
class Website { private: string URL; //1 unsigned int IP; //2 public: Website() : IP(0), URL("") {} // initialized in reverse order }; In the mem-initialization list, the programmer first initializes the member IP and then URL, even though IP is declared after URL. The compiler transforms the initialization list to the order of the member declarations within the class. In this case, the reverse order is harmless. When there are dependencies in the order of initialization list, however, this transformation can cause surprises. For example:
class Mystring { private: char *buff; int capacity; public: explicit Mystring(int size) : capacity(size), buff (new char [capacity]) {} undefined behavior
}; The mem-initialization list in the constructor of Mystring doesn't follow the order of declaration of Mystring's members. Consequently, the compiler transforms the list like this:
explicit Mystring(int size) : buff (new char [capacity]), capacity(size) {} The member capacity specifies the number of bytes that new has to allocate, but it hasn't been initialized. The results in this case are undefined. There are two ways to avert this pitfall: Change the order of member declarations so that capacity is declared before buff, or move the initialization of buff into the constructor's body. Copy Constructor A copy constructor initializes its object with another object. If there is no user-defined copy constructor for a class, C++ implicitly declares one. A copy constructor is said to be trivial if it's implicitly declared, if its class has no virtual member functions and no virtual base classes, and if its entire direct base classes and embedded objects have trivial copy constructors. The implicitly defined copy constructor performs a memberwise copy of its sub-objects, as in the following example:
#include using std::string; class Website //no user-defined copy constructor { private: string URL; unsigned int IP; public: Website() : IP(0), URL("") {} }; int main () { Website site1; Website site2(site1); //invoke implicitly defined copy constructor } The programmer didn't declare a copy constructor for class Website. Because Website has an embedded object of type std::string, which happens to have a user-defined copy constructor, the implementation implicitly defines a copy constructor for class Website and uses it to copy-construct the object site2 from site1. The synthesized copy constructor first invokes the copy constructor of std::string, and then performs a bitwise copying of the data members of site1 into site2. Novices are sometimes encouraged to define the four special member functions for every class they write. As can be seen in the case of the Website class, not only is this unnecessary, but it's even undesirable under some conditions. The synthesized copy constructor (and the assignment operator, described in the next section) already "do the right thing." They automatically invoke the constructors of base and member sub-objects, they initialize the virtual pointer (if one exists), and they perform a bitwise copying of fundamental types. In many cases, this is exactly the programmer's intention anyway. Furthermore, the
synthesized constructor and copy constructor enable the implementation to create code that's more efficient than user-written code, because it can apply optimizations that aren't always possible otherwise.
Destructor A destructor destroys an object of its class type. It takes no arguments and has no return type (not even void). const and volatile qualities are not applied on an object under destruction; therefore, const, volatile, or const volatile objects may have a destructor. If no user-defined destructor exists for a class, the implementation implicitly declares one. A destructor is trivial if it's implicitly declared and if its direct-base classes and embedded objects have trivial destructors. Otherwise, the destructor is nontrivial. A destructor invokes the destructors of the direct base classes and member objects of its class. The invocation occurs in the reverse order of their construction. Explicit Destructor Invocation C++ automatically invoke destructors in the following cases:
• • • • •
For static objects at program termination For a local object when the block in which the object is created exits For a temporary object when the lifetime of the temporary object ends For objects allocated on the free store using new, through the use of delete During stack unwinding that results from an exception
You can also call a destructor explicitly. For example:
class C { public: ~C() {} };
void destroy(C& c) { c.C::~C(); //explicit destructor activation } A destructor can also be explicitly invoked from within a member function of its object:
void C::destroy() { this->C::~C(); } In particular, explicit destructor invocation is necessary for objects that were created by the placement new operator (placement new is discussed in the section "Memory Management"). C++ distinguishes between two types of objects: POD (plain old data) and non–POD objects. A POD object has one of the following datatypes: a built-in type, pointer, union, struct, array, or class with a trivial constructor. For example:
int n; class C { public: int j,k; }; C c; // c is a POD object struct S { int j,k; }; S s; char *pc; bool barr[10]; Conversely, a non–POD object is one for which a nontrivial constructor exists. Note that this distinction between POD and non–POD doesn't exist in pure object-oriented languages; it's an artifact of the hybrid nature of C++. It's used to differentiate between traditional C datatypes and real C++ objects. A POD object begins its lifetime when it obtains storage with the proper alignment and size for its type, and its lifetime ends when the storage for the object is either reused or deallocated. A non–POD object begins its lifetime after its constructor has executed; its lifetime ends when its destructor has started.
Memory Management C++ has three types of storage (memory): automatic storage, static storage, and the free store. Each of these storage types has different semantics of object initialization and lifetime. The following sections explain the differences between these storage types and show how to use them effectively and safely.
void f(const std::string & s); //s' storage type s is //determined by the caller void g(register int n); //arguments passed by value are automatic int main() { int n;
// automatic because local,
non-static, non-extern
register int i; auto double d;
// register implies automatic // auto implies automatic
g(n); //passing a copy of n; the copy is automatic std::string s; // automatic because local, non-static, non-extern f(std::string temp()); // a temp object is also automatic
} Automatic storage Local objects that are not explicitly declared static or extern, local objects that are declared auto or register, and function arguments have automatic storage. This type of storage is also called stack memory. The following example contains various declarations, objects, and variables with an automatic storage type:
void f(const std::string & s); //s' storage type s is //determined by the caller void g(register int n); //arguments passed by value are automatic int main() { int n;
// automatic because local,
non-static, non-extern register int i; auto double d;
// register implies automatic // auto implies automatic
g(n); //passing a copy of n; the copy is automatic std::string s; // automatic because local, non-static, non-extern f(std::string temp()); // a temp object is also automatic } Automatic objects are created automatically upon entering a function or a block. They are destroyed when the function or block exits. Thus, on each entry into a function or a block, a fresh set of its automatic objects is created. The default value of automatic variables and non-class objects is indeterminate.
Static Storage Global objects, static data members of a class, namespace variables, and static variables in functions reside in static memory. A static object resides in the same memory address throughout the program's execution. Every static object is constructed only once during the lifetime of the program. By default, static data is initialized to binary zeros. Static objects with a nontrivial
constructor—that is, a constructor that's implemented either by the programmer or by C++ (see the section "Special Member Functions: Constructors, Destructors, and the Assignment Operator")—are subsequently initialized by their constructors. The scope of an object that's declared static within a function is restricted to that function. Objects with static storage are included in the following examples:
int num; //global variables have static storage int func() { static int calls; //initialized to 0 by default return ++calls; }
class C { private: static bool b; };
namespace NS { std::string str; //str has static storage
} Heap Memory Free store memory, also called heap memory (this term is used in C) or dynamic memory, contains objects and variables created by the operator new. Objects and variables that are allocated on the free store persist until they're explicitly released by a subsequent call to the operator delete. Failing to call delete results in memory leaks; in the case of objects with a destructor, the result is undefined behavior. Unlike with static objects, the address of an object allocated on the free store is determined at runtime. (Auto objects are allocated when the function or block using them is called.) The initial value of raw memory (a char array, as opposed to a class object) allocated by new is unspecified. C++ distinguishes between plain, or scalar new and delete, which allocate and deallocate a single object, respectively; and new[] and delete[], which operate on arrays. For example:
void f(const std::string & s); //s' storage type s is //determined by the caller int *p = new int; char *s = new char[1024]; Shape *ps=new Triangle; std::string *pstr=new std::string
f(pstr); delete p; delete[] s; //s is an array delete ps; //invokes the destructor delete pstr; //ditto
POD (Plain Old Data) and Non–POD Objects The constructor, copy constructor, assignment operator, and destructor automate most of the tedium associated with creating, copying, and destroying objects. The symmetry between a constructor and a destructor in C++ is rare among object-oriented programming languages, and it serves as the basis for advanced design idioms. Each C++ object possesses the four member functions; they're either declared by the programmer or implicitly declared. An implicitly declared special member function can be trivial, which means that C++ doesn't define it. The synthesized special member functions perform only operations that are required by the implementation. User-written special member functions are automatically augmented by the compiler to ensure the proper initialization of base and embedded sub-objects and the virtual pointer. A mem-initialization list is necessary for the initialization of const and reference data members, as well as to pass arguments to a base or embedded sub-object. In all other cases, a mem-initialization list is optional but can enhance performance.
malloc() and free() Versus new and delete C++ still supports the C library functions malloc() and free(). This backward compatibility with C is useful in three cases:
• • •
Combining original C legacy code with C++ programs Writing C++ code that's meant to be supported in C environments Implementing or overriding new and delete by calling malloc() and free()
Otherwise, malloc() and free() are not to be used in C++ code because they don't support object semantics. Furthermore, the results of calling free() to release an object that was allocated by new, or of using delete to release memory that was allocated by malloc(), are undefined. The C++ standard doesn't guarantee that the underlying implementation of operator new uses malloc(); in fact, on some implementations malloc() and new use different heaps. With new and delete you may call the asoosited constructor and distructor automatically …
Support for Object Semantics new and delete automatically construct and destroy objects. malloc() and free(), on the other hand, merely allocate and deallocate raw memory from the heap. In particular, using malloc() to create a non–POD object causes undefined behavior:
//disastrous! std::string *pstr =(std::string*)malloc(sizeof(std::string));
Safety Operator new automatically calculates the size of the object that it constructs. Conversely, with malloc(), the programmer has to specify explicitly the number of bytes that have to be allocated. In addition, malloc() returns void *, which has to be explicitly cast to the desired type. This is both tedious and
dangerous. Operator new returns a pointer to the desired type, so no explicit typecast is required. For example:
void func() { int * p = static_cast malloc(sizeof(int));//fine but tedious int * p2 = new int; }
Allocating and Deallocating Arrays Using new[] and delete[] new[] allocates an array of objects of a specified type. The return value of new[] is the address of the first element in the allocated array. For example:
int main() { int *p = new int[10]; bool equal = (p == &p[0]); //true delete[] p; return 0; } To release objects allocated by new[], you must call delete[]. Using delete instead of delete[] or vice versa will cause undefined behavior. This is because when new[] executes, C++ caches the number of elements in the allocated array somewhere. delete[] retrieves this cached value, thereby destroying the correct number of elements. Contrary to popular belief, the same rules apply to arrays of built-in types, not just to arrays of objects. Although delete[] doesn't invoke destructors in this case, it still has to retrieve the number of elements in the array to calculate the complete size of the memory block.
Dealing with Exceptions In pre–Standard C++, new returned a NULL pointer when it failed to allocate the requested amount of memory. In this regard, new behaved like malloc() in C. Programmers had to check the return value of new to make sure that it was not NULL. For example:
void f(int size) //anachronistic usage of new { char *p = new char [size]; if (p)
//this was fine until 1994
{ //...use p safely delete [] p;
} else { //...handle allocation failure } }
const int BUF_SIZE = 1048576L;
int main() { f(BUF_SIZE); return 0; } Returning a NULL pointer upon failure was problematic. It forced programmers to test the return value every time they called new. This is a recipe for human error and code bloat. Failures in dynamic memory allocation are rather rare and generally indicate an unstable system state. This is exactly the kind of runtime errors that exception handling was designed to cope with. For these reasons, the C++ standardization committee changed the specification of new nearly a decade ago. The C++ standard now states that the operator new should throw an exception of type std::bad_alloc when it fails, rather than returning a NULL pointer. A program that calls new either directly or indirectly (for example, if it uses STL containers that in turn allocate memory using new) must contain an appropriate handler to catch a std::bad_alloc exception. Otherwise, whenever new fails, the program will abort due to an uncaught exception. The exception-throwing policy also implies that testing the result of new is completely useless. If new is successful, the redundant test wastes system resources. On the other hand, in the event of an allocation failure, the thrown exception will abort the current execution flow, so the test won't execute anyway. The revised, standard-conforming form of the previously presented program looks similar to the following:
void f(int size) //standard-conforming usage of new { char *p = new char [size]; //...use p safely delete [] p; return; } #include #include using namespace std;
const int BUF_SIZE = 1048576L;
int main() { try { f(BUF_SIZE); } catch(bad_alloc& ex) //handle exception thrown from f() { cout<) and comes in two flavors: one for scalar new and another for new[]:
//exception-free versions of new and new[] defined in the header
void* operator new(std::size_t size, const std::nothrow_t&) throw(); void* operator new[](std::size_t size, const std::nothrow_t&) throw(); The exception-free new is also called nothrow new. It's used as follows:
#include #include using namespace std;
void f(int size) // demonstrating nothrow new { char *p = new (nothrow) char [size]; //array nothrow new
if (p == 0) { //...use p delete [] p; } string *pstr = new (nothrow) string; //scalar new if (pstr == 0) { //...use pstr delete [] pstr; } return; }
const int BUF_SIZE = 1048576L;
int main() { f(BUF_SIZE); return 0; }
Placement new An additional version of operator new enables you to construct an object or an array of objects at a predetermined memory position. This version is called placement new and has many useful applications, including building a custom-made memory pool or a garbage collector. Additionally, it can be used in mission-critical applications because there's no danger of allocation failure; the memory that's used by placement new has already been allocated. Placement new is also faster because the construction of an object on a preallocated buffer takes less time.
Member Alignment The size of a class or a struct might be larger than the sum of its member's sizes. This is because the compiler is allowed to insert padding bytes between members whose size doesn't fit exactly into a machine word. For example:
#include using namespace std;
struct Person { char firstName[5]; int age; // int occupies 4 bytes char lastName[8]; }; //the actual size of Person is most likely larger than 17 bytes On a 32-bit architecture, the compiler may insert three padding bytes between the first and the second members of Person, increasing its size to 20 bytes. Therefore, always sizeof() to obtain the correct size of an object:
memset(&p, 0, sizeof(Person));
Overriding new and delete For most programming tasks, the default implementation of new and delete is sufficient. In fact, many C++ programmers get along without even knowing that they can override these operators. Yet, redefining these operators for a given class is essential in certain advanced programming tasks. One example might be when you need to ensure that all instances of a class are allocated from a custom memory pool instead of the free-store. (You can achieve something similar by using placement new, but that doesn't block users from using global new). There are other useful applications of overriding new and delete: implementing a garbage collector, or ensuring that objects are allocated on a specific memory address (such as with a video card's internal memory buffer). In this section, I'll show how to override these operators, first on a per-class basis, and then globally. Declaring new and delete as Class Members Suppose you want to override new and delete for class A. Your first step is to declare these operators as member functions of this class:
#include // for size_t class A { public: A(); ~A(); static void* operator new (size_t size); static void operator delete (void *p); }; When you declare new and delete as class members, they are implicitly declared static. Still, it's advisable to add the keyword static to their declarations to document this property explicitly. Implementation The implementation of new is straightforward: it calls a custom allocation function, say, allocate_from_pool(), and returns the resulting pointer. You can use any other memory allocation
function that suits your needs, such as malloc() or GlobalAlloc(), as long as that function meets the memory alignment requirement of your objects. Here's a typical implementation of new:
void* A::operator new (size_t size) { void *p=allocate_from_pool(size); return p; } // A's default ctor implicitly called here Note that when this function exits, the class's default constructor executes automatically and constructs an object of type A. The matching version of delete looks as follows:
void A::operator delete (void *p) { release(p); // return memory to pool } // A's dtor implicitly called at this point C++ guarantees that an object's destructor is automatically called just before delete executes. Therefore, you shouldn't invoke A's destructor explicitly (doing so would cause undefined behavior as the destructor will actually run twice). Additional Customizations Overriding new enables you to customize its functionality in various ways. For instance, you may add an error handling mechanism to the existing implementation by defining a special exception class mem_exception. An object of this class will be thrown in case of an allocation failure:
class mem_exception {}; void* A::operator new (size_t size) { void *p=allocate_from_pool(size); if (p==0) throw mem_exception(); return p; } In a similar vein, you can extend delete's functionality to report the amount of available memory, write a message to a log file, and so on:
#include // for time() void A::operator delete (void *p) { release(p); cout << "available pool size: " << get_pool_size();
write_to_log("deletion occurred at: ", time(0)); } Usage of new and delete You use the overriding new and delete as you would use the built-in version of these operators; C++ automatically selects the overriding versions if they have been overridden in a specific class. Classes for which no overriding versions exist continue to use the built-in versions. For example
int main() { A *p=new A; // A::new delete p; // A::delete B *q=new B; // global built-in new delete q; // global built-in delete } Overriding new and delete Globally Until now, I've focused on a class-based override. What if you want override new and delete not just for one class, but for the entire application? C++ allows you to do that by defining global versions of these operators. Unlike a class-based override, the global new and delete are declared in the global namespace. (Remember that you cannot declare these operators in a different namespace.) This technique may be useful if you use an older version of Visual C++ (versions 6.0 and below) and other slightly outdated compilers. The implementation of new in Visual C++ isn't standard compliant: new returns NULL upon failure instead of throwing a std::bad_alloc exception, as required by the C++ ANSI/ISO standard. The following example overrides global new and delete to force standard compliant behavior:
#include // for std::bad_alloc #include #include // for malloc() and free()
// Visual C++ fix of operator new
void* operator new (size_t size) { void *p=malloc(size); if (p==0) // did malloc succeed? throw std::bad_alloc(); // ANSI/ISO compliant behavior return p; } The matching delete looks as follows:
void operator delete (void *p) { free(p); } Now you can use try and catch blocks to handle potential allocation exceptions properly, even if your compiler isn't yet fully-compliant in this regard:
int main() { try { int *p=new int[10000000]; // user-defined new //..use p delete p; // user-defined delete } catch (std::bad_alloc & x) { std::cout << x.what(); // display exception } }
Very few programming languages allow you to access and modify their inner-workings as does C++. Indeed, overriding new and delete is a very powerful feature: it gives you tighter control over the language's memory management policy and enables you to extend its functionality in various ways. However, the built-in implementation of new and delete is suitable for most purposes. Don't override these operators unless you have compelling reasons to do so, and when doing so, remember always to override both of them.
Linkage Types Objects, references, functions, types, templates, and namespaces are all considered names. A name can have one of three linkage types: external linkage, internal linkage, or no linkage. The linkage type of a name specifies its visibility from other scopes and translation units. A name with external linkage can be referred to from every translation unit of the program. Examples of such names include ordinary functions that aren't explicitly declared as static, global objects, const objects explicitly declared extern, classes, enumerations and their enumerators, templates, namespaces, and so on. Here are a few examples of names with external linkage:
int n; //global non-static, hence external linkage class C { void f(); // member functions
static int n;// static data members }; extern const K; //defined in a different translation unit void func (); namespace NS { class D{}; // qualified name NS::D has external linkage } enum DIR { Up, Down } // DIR, Up, and Down have external linkage A name with internal linkage is visible only from within the translation unit in which it was declared. A name declared in a namespace scope (that is, declared globally or within a namespace) has internal linkage if it's the name of a static object, a static function, a member of an anonymous union, a member of an anonymous namespace, a typedef name, or a const object not declared extern. Here are some examples of names with internal linkage:
static void f(); //a static function static int q; //a static object declared in global scope namespace //members of anonymous namespace { class C{}; int x; } const M=1000; //const object not declared extern union{ //members of an anonymous union int x; float y; }; typedef int I; // typedef names Names with no linkage are visible only in the scope in which they're declared. Such names include local objects, local classes, and other local types. Put differently, any name that has neither external linkage nor internal linkage has no linkage. Here are some examples of such names:
int main()
{ class C{}; // C is a local class; has no linkage int j; // local object not declared extern has no linkage C c; // the object c has no linkage enum Parity // local enum and enumerators { Even, Odd }; }
Guidelines for Effective Memory Management Choosing the correct type of storage for an object is a critical implementation decision because each type of storage has different implications for the program's performance, reliability, and maintenance. Choosing the correct type of storage will help you avoid common pitfalls and performance penalties, as I'll show momentarily. In addition, the following sections discuss general topics that are associated with the unique memory model of C++, and compare C++ to other languages. Preferring Automatic Storage to Free Store When compared to automatic storage, creating objects on the free store is more expensive in terms of performance for several reasons:
•
• •
Runtime overhead. Allocating memory from the free store involves negotiations with the operating system. When the free store is fragmented, finding a contiguous block of memory can take even longer. In addition, the exception-handling support in the case of allocation failures adds runtime overhead. Maintenance. Dynamic allocation might fail; additional code is required to handle such exceptions. Safety. An object might be accidentally deleted more than once, or it might not be deleted at all. Both of these are a fertile source of bugs and runtime crashes in many applications.
The following code sample demonstrates two common bugs that are associated with allocating objects on the free store:
#include using namespace std; void f() { string *p = new string; //...use p if (p->empty()== false) { //...do something
return; //OOPS! memory leak: p was not deleted } else //string is empty { delete p; //..do other stuff } delete p; //OOPS! p is deleted twice if isEmpty == true } Such bugs are quite common in large programs that frequently allocate objects on the free store. Often, it's possible to create objects on the stack, thereby simplifying the structure of the program and eliminating such potential bugs. Consider how the use of a local string object simplifies this function:
#include using namespace std; void f() { string s; //...use s if (s.empty()!= false) { //...do something return; } else { //..do other stuff } } As a rule, automatic and static storage types are always preferable to free store. Instantiating a Local Object This is the correct form of instantiating a local object:
string str;
//no parentheses
Empty parentheses are allowed after the class name,
string str(); //entirely different meaning but this statement has an entirely different meaning. It's parsed as a declaration of a function named str, which takes no arguments and returns a string by value. Zero Initialization The literal 0 is of type int. However, it can be used as a universal initializer for every fundamental datatype. Zero is a special case in this respect because the compiler examines its context and automatically casts accordingly. For example:
void *p = 0; //zero is implicitly converted to 'void *' float salary = 0;
// 0 is cast to a float
char name[10] = {0};
// 0 cast to a '\0'
bool b = 0; // 0 cast to 'false' void (*pf)(int) = 0;
// pointer to a function
int (C::*pm) () = 0; //pointer to a class member An uninitialized pointer has an indeterminate value. Such a pointer is often called a wild pointer. It's almost impossible to test whether a wild pointer is valid, especially if it's passed as an argument to a function. For example:
void func(char *p );
int main() { char * p; //dangerous: uninitialized //...many lines of code; p left uninitialized by mistake if (p) //erroneously assuming that a non-null value indicates //a valid address { func(p);
// func has no way of knowing whether p
//has a valid address } return 0; } Even if your compiler initializes pointers automatically, it's best to initialize them explicitly to ensure code readability and portability. As noted previously, POD objects with automatic storage have an indeterminate value by default. However, you can initialize automatic POD objects explicitly when necessary. One way to initialize automatic POD objects is by calling memset(). However, there's a much simpler way to do it:
struct Person
{ long ID; int bankAccount; bool retired; };
int main() {
Person person ={0}; //ensures that all members of //person are initialized to binary zeros return 0; } This technique is applicable to every POD struct. It relies on the fact that the first member is a built-in datatype. The initializer zero is automatically cast to the appropriate built-in type. C++ guarantees that whenever the initialization list contains fewer initializers than the number of members, the rest of the members are initialized to binary zeros as well. Note that even if the definition of Person changes and members are added, all its members are still initialized. The same initialization technique is also applicable to local automatic arrays of fundamental type:
void f() { char name[100] = {0}; //all array elements are initialized to '\0' float farr[100] = {0}; //all array elements are initialized to 0.0 int iarr[100] = {0}; //all array elements are initialized to 0 void *pvarr[100] = {0};//array of void *; all elements //are initialized to 0 //...use the arrays } This technique works for any combination of structs and arrays:
struct A { char name[20]; int age; long ID; };
void f() { A a[100] = {0}; } Deleting Pointers The result of applying delete to the same pointer after it has been deleted is undefined. Clearly, this bug should never happen. However, it can be prevented by assigning a NULL value to a pointer immediately after it has been deleted. Deleting a NULL pointer is harmless:
#include using namespace std; void func { string * ps = new string; //...use ps if ( ps->empty() ) { delete ps; ps = 0; //safety measure } //...many lines of code delete ps; // harmless }
Effective and bug-free use of the diversity of C++ memory-handling constructs and concepts requires a high level of expertise and experience. It isn't an exaggeration to say that most of the bugs in C/C++ programs are related to memory management. However, this diversity also renders C++ a multipurpose, nocompromise programming language. The complex memory model of C++ enables maximum flexibility. The three types of data storage— automatic, static, and free store—provide a level of control that no other language offers. The fundamental constructs of dynamic memory allocation are the operators new and delete. Each of these has no fewer than six different versions: scalar and array variants, each of which comes in three flavors (exception throwing, exception free, and placement). Many object-oriented programming languages have a built-in garbage collector, which is an automatic memory manager that detects unreferenced objects and reclaims their storage. The reclaimed storage can then be used to create new objects, thereby freeing the programmer from having to explicitly release dynamically allocated memory. Having an automatic garbage collector is handy because it eliminates a major source of bugs, runtime crashes, and memory leaks. However, garbage collection is not a panacea. It incurs additional runtime overhead due to repeated compaction, reference counting, and memoryinitialization operations. The overhead of these operations may be unacceptable in time-critical applications. Furthermore, when garbage collection is used, destructors are not necessarily invoked immediately when
you destroy an object, but at an indeterminate time afterward. For these reasons, C++ doesn't provide a garbage collector. Nonetheless, there are techniques to minimize the perils and drudgery of manual memory management, without the associated disadvantages of garbage collection. The easiest way to ensure automatic memory allocation and deallocation is to use automatic storage. For objects that have to grow and shrink dynamically, you can use STL containers that automatically adjust their size. Finally, in order to create an object that exists throughout the execution of a program, you can declare it static.
Template A template is a mold from which the compiler generates a family of classes or functions. C++ programming styles and concepts have changed considerably since the introduction of templates in 1991. Initially, templates were viewed as a support for generic container classes such as Array and List. In recent years, the experience of using templates has shown that this feature is most useful in designing and implementing general-purpose libraries such as the Standard Template Library (STL), which is discussed in the section "The Standard Template Library (STL) and Generic Programming." With the widespread use of templates, C++ added more sophisticated constructs to control template behavior and performance. Such constructs include partial specializations, explicit specializations, template members, default type arguments, and so on. The following sections discuss all of this and more. Many algorithms and data structures can be defined independently of the concrete datatypes that they manipulate. The concept of a complex number, for instance, is not exclusively limited to double. Rather, it's applicable to every floating-point type. Designing a type-independent class that abstracts the concept of a complex number enables users to choose the desired level of precision for a specific application without having to duplicate code manually. In addition, type-independent classes are portable among different platforms and locales. A class template is declared using the keyword template, followed by a template parameter list enclosed in angle brackets (<>) and a declaration or a definition of the class. For example:
template class Vector; //declaration template class Vector //definition { private: size_t sz; T * buff; public: explicit Vector(size_t s = 100); Vector (const Vector & v); Vector& operator= (const Vector& v); //assignment operator ~Vector(); //destructor //other member functions T& operator [] (unsigned int index); const T& operator [] (unsigned int index) const; size_t size() const; };
Member functions can be defined outside the class body. The following code sample contains out-of-class definitions of four member functions:
//definitions of Vector's member functions //follow the class declaration
//constructor definition template Vector::Vector (size_t s) : sz(s), buff (new T[s]) {} template //copy ctor Vector::Vector (const Vector & v) { sz = 0; buff = 0; *this = v; //use overloaded assignment operator }
template inline size_t Vector::size () const { return sz; }
template Vector::~Vector () //destructor { delete [] buff; } The prefix template indicates that T is a template parameter, which is a placeholder for a yet-unspecified type. The keyword class is of particular interest because the corresponding argument for the parameter T is not necessarily a user-defined type; it can also be a built-in type, such as char or int. If you prefer a more neutral term, you can use the typename keyword instead:
//typename instead of class //no semantic difference between the two forms template class Vector
{/**/}; template Vector::Vector (size_t s) : sz(s), buff (new T[s]) {} Within the scope of Vector, qualification with the parameter T is redundant, so the member functions can be declared and defined without it. The constructor, for example, can be defined as follows:
template class Vector { public: Vector (size_t s = 100); // equivalent to Vector (size_t s = 100); }; // equivalent to template Vector::Vector(size_t s) template Vector::Vector (size_t s) : buff (new T[s]), sz(s) {} Instantiation and Specialization A class template is not a "real" class. The process of instantiating a "real" class from a template is called template instantiation. A specialization consists of a template name followed by a list of arguments in angle brackets (for example, Vector). A specialization can be used exactly like any other class. Here are a few examples:
void func (Vector &); //function parameter size_t n = sizeof( Vector ); //sizeof expression class myStringVector: private Vector //base class {/*...*/}; cout<).name(); //typeid expression Vector vi; // creating an object The compiler instantiates only the necessary member functions of a given specialization. In the following example, points of member instantiation are numbered:
int main() { Vector vi(5); // 1 for (int i = 0; i<5; i++) { vi[i] = i; //fill vi cout<
// 2
} } //3 The compiler generates code only for the following Vector member functions, which are used either explicitly or implicitly in the program:
Vector::Vector (size_t s) //1: constructor : sz(s), buff (new int[s]) {}
inline int& //2: operator [] Vector::operator [] (unsigned int idx) { return buff[idx]; }
Vector::~Vector () //3: destructor { delete [] buff; } By contrast, code for the member function size_t Vector::size() const is not generated, as it's not required in this program. The "generate on demand" policy is a requirement of the C++ standard and has two functions:
• •
Efficiency. It's not uncommon for certain class templates to define hundreds of member functions (STL containers, for example); normally, however, fewer than a dozen of these are actually used in a program. Flexibility. In some cases, not every function defined in a class template is supported in the target platform or program. For example, a container class can use ostream's operator << to display objects for which an overloaded << is defined. However, a POD (plain old data) struct for which no overloaded version of << exists can still be stored in such a container, as long as the program doesn't call the << operator.
Template Arguments A template can take one or more type parameters; that is, symbols that represent an as-yet-unspecified type. For example:
template class Vector {/*...*/}; A template can also take ordinary types such as int and long as parameters:
template class Array {/*...*/}; Note, however, that when an ordinary type is used as a parameter, the template argument must be a constant or a constant expression of an integral type. For example:
const int cn = 5;
int num = 10; Array ac; // OK, 5 is a const Array af; // OK, cn is a const Array auc; // OK, constant expression used Array ab; // error, num is not a constant The only arguments allowed (other than constant expressions) are a pointer to a non-overloaded member, and the address of an object or a function with external linkage. This also implies that a string literal cannot be used as a template argument because it has a static storage type. A template can take a template as an argument:
int send(const Vector& ); int main() { //a template used as an argument Vector > msg_que(10); //...fill msg_que for (int i =0; i < 10; i++) //transmit messages send(msg_que[i]); return 0; } Note that when a template is used as an argument, the space between the right two angle brackets is mandatory:
Vector > msg_que(10); Otherwise, the >> sequence would be parsed as the right shift operator. Default Type Arguments Class templates can have default type arguments. As with default argument values of a function, the default type of a template gives the programmer more flexibility in choosing the optimal type for a particular application. For instance, the Vector template can be optimized for special memory management tasks. Instead of using the hard-coded size_t type for storing the size of a Vector, it can have a size type as a parameter. For most purposes, the default type size_t is used. However, for managing extremely large memory buffers (or very small ones), the programmer is free to choose other suitable datatypes instead. For example:
template class Vector {/*..*/}; Vector ordinary; //second argument is size_t Vector tiny(5);
The generic nature of templates enables you to define molds of classes and functions from which compilers generate concrete instances, or specializations. For example, the primary template std::vector may produce the following specializations:
vector vi; vector vs; vector vd; //...and so on. Likewise, function templates, such as std::random_shuffle(), can generate a sequence of integers, string, files, etc. The type-unawareness of templates is what makes them so useful. Yet there are times when type-unawareness becomes a problem. The solution is using explicit template specializations and partial specializations to override the default behavior of a primary template in special cases. A partial specialization of a class template overrides the primary template for specific specializations. The classic example is a primary template that handles concrete types such as int, std::string, CWnd etc., and a partial specialization thereof for pointers. The distinction between pointers and non-pointer types is needed, for example, when you access members of a Vector's elements:
v[0].destroy();//vector of non-pointers vp[0]->destroy(); //vector of pointers A partial specialization of a class template must appear after the primary template. The following partial specialization of Vector defines an overriding implementation that the compiler uses for every template argument that is a pointer type (the definition of the primary template is repeated for convenience):
template class Vector //primary { public: size_t length() const; void push_back(const T &r); //.. };
template class Vector //partial specialization { public: void push_back(const T *p); size_t length() const {return vecp.size();} private: std::vector vecp; };
A partial specialization looks like a primary template, except that it contains a set of template arguments (T* in this example) after the class name, right before the opening brace. Consequently, whenever you instantiate a Vector whose template argument is a pointer, the compiler will choose the partial specialization instead of the primary template. It's possible to define a set of partial specializations, each applying to a different subset of template arguments. For example, you can define a partial specialization for all pointer types using as the argument list, a set of pointers to volatile objects that is used in event-driven systems:
class Vector //another partial specialization { public: void push_back(const volatile T *p); //.. }; And so on. The partial specializations must be ordered: a least specialized version should be defined before a more specialized version. Intuitively, we know what "a more specialized version" means. However, there is also a formal definition: a partial specialization X is more specialized than a partial specialization Y if every valid template argument for X is also a valid argument for Y, but not vice versa. Let's see how this formalization works:
Vector ;//primary #1 Vector; //partial specialization #2 Vector;//another partial specialization #3 Let's use three arguments: int, int *, volatile int * to instantiate Vectors:
Vector vi; Vector vpi; Vector vpiv;; vi uses the primary template because the argument int is not a pointer type. Notice that if we hadn't defined the partial specializations, the compiler would have picked the primary template, substituting T for 'int *'. What about vpi? Here, the argument can match the two partial specializations #2 and #3. However, the compiler picks the Vector partial specialization because it's a better match for the argument's type. Vector is the most specialized version because pointers to volatile objects are a subset of all possible pointer types — while every pointer to non-volatile can be converted to volatile T*, the reverse isn't true. Therefore, the set of is more specialized than
Explicit Specializations of a Class Template An explicit specialization of a class template provides an alternative definition of the primary template. It's used instead of the primary definition (or a partial specialization) if the arguments match those that are given in the explicit specialization. When is an explicit specialization useful? Consider the Vector template: The code generated by the compiler for the specialization Vector is very inefficient. Instead of storing every Boolean value in a single bit, it occupies at least an entire byte. Following is an example of an explicit specialization Vector that manipulates bits rather than bytes:
template <> class Vector //explicit specialization { private: size_t sz; unsigned char * buff; public: explicit Vector(size_t s = 1) : sz(s), buff (new unsigned char [(sz+7U)/8U] ) {} Vector (const Vector & v); Vector& operator= (const Vector& v); ~Vector(); //...other member functions }; Vector< bool> bits(8); bits[0] = true; //assign bool seventh = bits[7]; The template<> prefix indicates an explicit specialization of an existing primary template. The template arguments for an explicit specialization are specified in the second pair of angle brackets – those that immediately follow the class name. The specialization hierarchy of Vector that has been defined thus far is as follows:
template class Vector //primary template #1 {...}; template class Vector //partial specialization #2 {...}; template class Vector //partial specialization #3 {...}; template <> class Vector //explicit specialization #4 {}; An explicit specialization differs from a partial specialization in that it applies to a specific template argument, say bool, whereas the latter applies to a set of template arguments – pointers, for example. An explicit specialization should be declared after the primary template and its partial specializations. NOTE As a side note, it's worth mentioning that the Standard Template Library already defines a specialization of std::vector for manipulating bits optimally. Alas, during the past five years, std::vector has fallen from grace in the eyes of the C++
standardization committee as well as other people for various reasons that discussed in The Standard Template Library (STL) and Generic Programming. A function template declaration contains the keyword template, followed by a list of template parameters and a function declaration. As opposed to ordinary functions, which are usually declared in a header file and defined in a separate .cpp file (unless the template is exported), a function template is defined inside a header file (which means that it may be #included in multiple compilation sessions):
//++file max.h template T max( T t1, T t2)//definition in a header file { return (t1 > t2) ? t1 : t2; } Unlike class template parameters, function template parameters are implicitly deduced from the types of their matching arguments. In the following example, the compiler instantiates three distinct specializations of max(), according to the types of the arguments used in the place of instantiation:
int i = 0, j = 8; char c = 'a', d = 'z'; std::string s1 = "first", s2 = "second"; int nmx = max(i, j); char cmx = max(c, d);
// int max (int, int); // char max (char, char);
std::string smax = max(s1, s2); std::string);
// std::string max (std::string,
This implementation of max() isn't ideal, to say the least. The arguments and the return type are passed by value. When the template argument is a class object, say std::string, this causes the creation of multiple temporaries. Therefore, it's better to pass template parameters by reference. As usual, if the template function doesn't modify its arguments, pass them as reference to const:
template const T& max( const T & t1, const T & t2)//definition { return (t1 > t2) ? t1 : t2; } In many cases, the implicit type deduction of a function template is satisfactory. However, when the function template takes no arguments or when you want to override the default type deduction, it is possible to specify the template's arguments explicitly as follows:
max (true, false); //override the default deduction of type bool template bool func() // no arguments { T t1, t2; return t1==t2;
}
// enforce a compile-time constraint: "T must be a comparable type" bool res=func(); //explicit argument specification res=func();//ditto Overloading and Partial Specialization As opposed to class templates, a function template doesn't support partial specializations; instead, you use overloading. Let's look at an example:
const char *p1="string1"; const char *p2="string2"; const char *maxstr max(p1, p2);//bad! The max() call causes the compiler to generate the following specialization:
const char * max(const char *, const char *); The problem is that this specialization compares pointer values, instead of a performing a lexicographical comparison. To override this default behavior, you can add an overloaded version of max() that will be used for arguments of type char * (and their cv-qualified flavors):
const char * max(const char *p1, const char *p2) { int val=std::strcmp(p1, p2); if (val>0) return p1; return p2; }
int main() { double d=max(5.0, 6.0); //1 const char * p=(p1,p2);//2 } The first max() call in main() uses the definition of the primary function template max(), generating the following specialization from it:
const int& max(const int&, const int&); However, the second max() call uses the const char* overloaded version.
It looks as if we're splitting hairs here. Whether it's called partial specialization or overloading, the compiler picks the right version of the function, so is there really any difference between the two mechanisms? Yes, there is. In fact, there's more than one. Partial specialization doesn't introduce a new template; it merely extends an existing template. However, an overloaded version introduces a new function, completely independent of any other overloads. When the compiler has to choose which template version to use, it considers all of the overloaded versions together, using the overload resolution rules to select the best fit. By contrast, when a class template is looked up, only the primary template is considered first. Then, if the compiler finds a partial specialization of that template with template arguments that match the instantiation, the partial specialization's definition is used. There are other differences between partial specialization and overloading:
• • •
You can specialize a member template of a class (i.e., a member function that is a template) without changing that class' definition. However, it's impossible to add an overloaded version of a member function without editing the class' definition. When selecting templates, the argument matching rules are stricter than those of function overloading. Therefore it is possible to define specializations that rely on subtle parameter differences, such as T* vs. const T*. When you declare a function template f(T) as a friend, all instances thereof, say f, f etc., are granted the same privileges. However, you have to declare each overloaded version as a friend.
Considering these differences, the proposal to add partial specialization of function templates to C++ seems reasonable. However, permitting both partial specializations and overloading of function templates could lead to various ambiguity problems. At present, this issue is still being reviewed by the standardization committee.
Member Templates Two terms in the C++ template jargon, template member and member template, sound confusingly similar. However, they aren’t interchangeable. A template member is a member declared inside a class template, for example:
template class C { T * p; // a template member void f(T ") const; // another template member }; By contrast, a member template is a template declared inside a class or a class template. Templates and Implicit Conversions Member templates are useful for solving an onerous problem: the lack of implicit conversions between different specializations of the same class template. Let’s look at an edifying example. In the following code fragment, the implicit conversion between numeric built-in types enables the programmer to use two variables of different types within the same expression:
int num=1; double dn=num; //1 implicitly converted to 1.0 if (num==dn) //same here These implicit conversions are trivial so you rarely pay attention to the fact that the compiler actually converts int to double here. However, when templates are involved, such implicit conversions don’t exist:
vector ai; vector ad; ai.push_back(10); ad=ai;//compilation error You can’t assign vector to vector because there is no standard conversion between these two independent specializations. In most cases, this is well and good; assigning vector makes no sense. Yet, in the case of vector and vector, you know intuitively what the result should be: each element of vector is converted to double and then inserted to the vector object. Obviously, we need to preserve the type safety of C++, allowing only meaningful assignments of template specializations. Member templates enable you to accomplish this. A Case Study Suppose you have a class template that represents a container:
template class Array { std::vector v; public: explicit Array(size_t sz=0) : v(sz) {} ~Array(); const T" operator[] (int idx) const; size_t size() const; T" operator[] (int idx); void push_back(const T" t); void clear(); //.. }; Assigning two Array objects of the same types works fine:
Array ai, aj; ai.push_back(5); aj=ai; //fine, implicit assignment operator used Array doesn’t declare an assignment operator. Instead, the compiler generated assignment operator is used in the assignment expression. Now suppose you want to assign two different objects:
Array a; Array d;
a.push_back(5); d=a; //compilation error This code doesn’t compile. Defining an Asymmetric Assignment Operator C++ textbooks teach you that a canonical assignment operator of class C takes const C" as a parameter and returns C". However, to allow for the assignment of different specializations, a different type of an assignment operator is needed. Such an assignment operator has no special name in the C++ literature. Therefore, I will refer to it as an asymmetrical assignment operator. Unlike a canonical assignment operator, the asymmetric assignment operator is implemented as a member template that uses two different template parameters: T and T2:
template class Array { //... public: //declaring a member template assignment operator template Array" operator=(const Array "); }; The return type is Array" whereas the parameter’s type is Array". The implementation of such an assignment operator depends on how your template stores its elements. Generally speaking, you need to break down the collection to its individual elements, assigning every Array[n] to its matching Array[n]. Here is a typical implementation:
template template Array" Array::operator=(const Array" t2) { if (this == (void*) "t2) //detect self assignment return *this;
clear(); //remove existing elements for (size_t i=0; i
template template sequence indicates a definition of a member template of a class template. If your compiler chokes on it, consider an upgrade! Assigning Different Specializations Now you can assign different Array specializations:
Array a; Array d; a.push_back(15); a.push_back(90); d=a; //OK, d contains the elements 15.0 and 90.0 Recall that the compiler-generated assignment operator (i.e., not the asymmetric one) is still in use when you assign objects that have the same type:
Array ai, aj; aj=ai; // uses compiler-generated operator= Type Safety The asymmetric assignment operator doesn’t compromise type safety. If you try to assign the following objects:
Array words; Array num; num=words; //compilation error ...You’ll get a compilation error because there is no implicit conversion of string to int. To conclude, the only valid assignments are:
• •
Assignments of identical types, e.g., Array to Array . In this case, the compiler generated assignment operator is at work. Assignments of specializations whose template arguments are convertible: Array to Array, Array to Array etc. In such assignments, the asymmetric assignment operator is used.
Templates automate the implementation of generic containers and functions. The two main template categories in C++ are class templates and function templates. A class template encapsulates parameterized data members and function members. Function templates are a means of implementing generic algorithms. Explicit specializations of a class template are always required. For function templates, the compiler usually deduces the specialization from the types of the arguments. It's possible to define partial specialization of a class template that overrides the primary class template for a set of types. A partial specialization is indicated by a secondary list of parameters following the name of the template. An explicit specialization enables the programmer to override the automatic instantiation of a class template for a certain type. Templates and operator overloading are the building blocks of generic programming. The Standard Template Library is an exemplary framework of generic programming, as you'll see in the section "The Standard Template Library (STL) and Generic Programming."
The separate compilation model enables us to define functions, types and objects in one translation unit and refer to them from other translation units. After compiling all the translation units of a program, the linker subsequently resolves all the references to extern symbols, producing a single executable file. When dealing with ordinary functions and classes, the separate compilation model works neatly. Templates, however are a different beast. When you instantiate a template, the compiler must see its definition. This is an explicit requirement in the C++ standard, which states that dependent names (names that depend on the type of a template parameter) shall be looked up in both the current context (i.e., the place of instantiation) and the context of the template's definition. The compiler cannot generate the code of a specialization without looking at the template's definition — even if the definition appears in a separate translation unit. If the template is defined in several source files, all the definitions must comply with the One Definition Rule. As I explained elsewhere, the common approach is to define the template in a header file and #include it in every source file that uses that template. If you have used templates before, you already know that. However, standard C++ defines another compilation model for templates known as the separation model.
export: How it All Began Right from the start, C++ creators called for separate compilation of templates. However, they didn't specify how this could be accomplished. Unlike most other C++ features, which were standardized only after being implemented by one vendor at least, exported templates were added to C++ in 1996 with no existing implementation whatsoever. In 1996, many compilers hardly supported ordinary templates and the C++ community had gained little experience with advanced template techniques such as meta-programming. Therefore, the implications of implementing export weren't fully recognized. The very few people who have implemented exported templates since agree that this is an arduous task indeed. State of the Art The most popular C++ compilers (Microsoft's Visual C++ .NET, Borland's C++ BuilderX, GNU's GCC and others) don't support export. Even vendors who have expressed their commitment to "100% ISO compliance" exclude export from their checklist. The frequently-cited reason for this is "lack of demand." Could it be that users don't demand this features because they've never had a chance to use it? Which compilers support export? In addition to Comeau C/C++, Intel's 7.x compiler also supports export, although by default, it's disabled and "currently undocumented and unsupported". Other EDG-derived implementations may also support this feature.
export and User Expectations If judged by the amount of questions pertaining to linkage errors due to the use of templates, C++ programmers indeed expect compilers to support separate template compilation. However, my impression is that they are looking for something quite different from what export actually does. One might naively assume that by declaring a template export in a header file, it would be possible to define it in a .cpp file that gets compiled only once, and then #include only the header file in other translation units:
//func.h export template void func(T t); //only a declaration //func.cpp template void func(T t) {//implementation //... } //main.cpp
#include "func.h" int main() { func(5); //instantiate void func(int) here } Indeed, compilers that support exported templates allow this. However, when the compiler sees the call to func(), it has to look at the template's definition, not just its declaration. How do export-enabled compilers accomplish this? When a file containing definitions of exported templates is compiled, Comeau C/C++ for instance creates a file with an .et suffix. Then, when the template in question is instantiated, the compiler uses the .et files to find the translation unit that defines a given exported template. The sources containing the exported template definitions must therefore be made available at the time of instantiation. The export facility is not a mechanism for avoiding the publication of template definitions in source form. In my opinion, this is the most crucial point in the debate about the usefulness of export. Many users mistakenly believe that export enables them to ship compiled .obj, .lib, or .dll files without having to provide the templates' definitions. This isn't the case. Future Directions Considering the strict requirements of the Standard, would it possible, at least theoretically, to avoid shipping the template definitions in source form? Vendors may come up with a technology for compiling a template's definition into a pseudo-code or some other intermediary language. However, such a compiler must be able to reconstruct the original template's definition from the intermediary code. .NET and Java already offer such a technology, with the obvious advantage of portability. In C++, I can't think of a compelling reason to adopt this approach. For developers who wish to protect their intellectual property by hiding templates' definitions, this solution is pretty useless since customers would be able to reconstruct the definitions from the intermediary code. Worse yet, compiling a template's definition into intermediary code and then decompiling it back during instantiation will increase build time considerably. Conclusions Considering its inherent complexities (both from an implementer's point of view and a user's point of view), export is expensive. Yet, it doesn't offer any breathtaking advantages. Worse, it incurs a few undesirable side-effects, such as delayed compilation errors and semantic differences from the inclusion model with respect to overload resolution and the "externalization" of file-scope identifiers. Then again, export is in the Standard (a proposal to remove it was recently rejected). Will this feature ever become a widely-used feature? My impression is that vendors will continue to ignore it, as they have been doing in the past eight years. Books C++ Templates: The Complete Guide, by David Vandevoorde and Nicolai M. Josuttis, is in my opinion the best template guide yet. In addition to covering state-of-the-art template programming techniques (which is why you should read this book in the first place), the authors also dedicate a few pages to the somewhat confusing template terminology, such as explaining the difference between a specialization and instantiation, or the difference between a template parameter and a template argument. Even export gets its share in chapter 6, where the authors discuss its semantics and usage. Namespaces are a mechanism that enables programmers to declare classes, functions, constants and other declarations collectively known as names in separate scopes. I'll use an analogy to explain why namespaces are necessary. Imagine that the file system on your computer had no directories or subdirectories. All files would be stored in a flat repository, visible all the time to every user and application. Consequently, extreme difficulties would arise: Filenames would clash and simple operations such as listing, copying or searching files would be much more difficult. Namespaces are similar to directories. They enable you to restrict the visibility of names to certain scopes while keeping them hidden from other scopes. This way, they protect your code from name clashes and provide a higher level of encapsulation.
In large-scale software projects, short and elegant names for classes, functions, and constants can cause name conflicts, because different developers might use the same name more than once to indicate different entities. In the pre-namespace era, the only workaround was to use various affixes in identifiers' names. This practice, however, is laborious and error prone:
class string // short but dangerous { // ... };
// safer but tedious class excelSoftCompany_string { //... }; Namespaces enable you to use convenient, short, and intelligible names safely. Instead of repeating the unwieldy affixes, you group your declarations in a namespace and factor out the recurring affix, like this:
//file excelSoftCompany.h namespace excelSoftCompany // a namespace definition { class string {/*..*/}; class vector {/*..*/}; } You may separate the definition from the declaration of a namespace member as follows:
#include using namespace std; namespace A { void f(); //declaration } void A::f() //in a separate file, definition { cout<<"in f"<
{ A::f(); } Namespaces are more than just directories or containers of names. In the following passages, I will discuss some of the namespaces' features and their use. A Fully Qualified Name A namespace is a scope in which declarations and definitions are grouped together. In order to refer to any of these from another scope, a fully qualified name is required. A fully qualified name has the form: namespace::classname::identifier. Since both namespaces and classes can be nested, the resulting name can be rather long but it ensures uniqueness:
unsigned int maxlen = std::string::npos; If repeating the fully qualified name seems tedious, you can use a using declaration or a using directive instead. A using-Declaration and a using-Directive A using-declaration consists of the keyword using followed by a namespace::member. It instructs the compiler to locate every occurrence of a certain namespace member (type, operator, function, constant, etc.) in the specified namespace, as if the fully-qualified name were used. For example:
#include //STL vector; defined in namespace std int main() { // the following is a using declaration; every //occurrence of vector is looked up in std using std::vector; vector vi; } A using-directive, on the other hand, renders all the names of a certain namespace accessible in the directive's scope. For example:
#include // belongs to namespace std #include // also in namespace std int main() { using namespace std; // a using directive //all and declarations //can now be accessed without //fully qualified names vector vi;
vi.push_back(10); cout<
//file excelSoftCompany.h namespace excelSoftCompany { class string {/*..*/}; class vector {/*..*/}; } You can access your own string class as well as the standard string class in the same program without risking name clashes like this:
#include // std::string #include "excelSoftCompany.h"
int main() { using namespace excelSoftCompany; string s; // referring to class excelSoftCompany::string std::string standardstr; // ANSI string } Namespace Aliases Choosing a short name for a namespace can eventually lead to a name clash -- the very same problem we wanted to avoid in the first place. However, very long namespaces are tiresome. For this purpose, you can use a namespace alias. In the following example, I define an alias called ESC for the unwieldy Excel_Software_Company namespace:
//file decl.h namespace Excel_Software_Company { class Date {/*..*/}; class Time {/*..*/}; }
//file calendar.cpp
#include "decl.h" int main() { namespace ESC = Excel_Software_Company; //alias ESC::Date date; ESC::Time time; } Argument-Dependent Lookup Andrew Koenig devised an algorithm known as Koenig lookup for resolving namespace members. This algorithm, also called argument-dependent lookup, is used in all standard-conforming compilers to handle cases like the following:
namespace MYNS { class C {}; void func(C); }
MYNS::C c; // global object of type MYNS::C
int main() { func(c); // OK, MYNS::f called } Neither a using-declaration nor a using-directive appears in the program. And yet, the compiler did the right thing -- it correctly identified the unqualified name func as the function declared in namespace MYNS by applying Koenig lookup. How does it work? Koenig lookup instructs the compiler to look at not just the usual places such as the local scope, but also the namespace that contains the argument's type. Thus, in the following source line, the compiler detects that the object c, which is the argument of the function func, belongs to namespace MYNS. Consequently, it looks at namespace MYNS to locate the declaration of func, "guessing" the programmer's intent.
func(c); // OK, MYNS::f called Without Koenig lookup, namespaces would impose an unacceptable burden on the programmer, who would have to repeatedly specify the fully qualified names, or instead, use numerous using-declarations. To push the argument in favor of Koenig lookup even further, consider the following example:
#include using std::cout;
int main() { cout<<"hi"; //OK, operator << //was brought into scope //by Koenig lookup } The using declaration injects std::cout into the scope of main(), thereby enabling the programmer to use the non-qualified name cout. However, the overloaded << operator, as you may recall, is not a member of std::cout. Rather, it's declared in namespace std as an external function that takes a std::ostream object as its argument. Without Koenig lookup, the programmer would have to write something like this:
std::operator<<(cout, "hi"); Fortunately, Koenig lookup "does the right thing" and saves the programmer from this tedium in an elegant way. Most C++ programmers are familiar with the basic concepts of namespaces. And yet, they tend to use namespaces passively, e.g., by yanking code and data from namespaces defined by a third-party. They rarely declare their own classes and functions in namespaces, though. In the following passage I will show that the task of declaring your classes and functions in a namespace isn't as intimidating as it might seem at first. Namespace members As previously said, a namespace is a scope that contains declarations of classes, functions, constants, templates etc. These are called namespace members. For example:
namespace proj_alpha { //the following are members of namespace proj_alpha class Spy {/*..*/}; void encrypt (char *msg); const int MAX_AGENTS = 8; } In this example, class Spy is implemented in a single source file. Normally, you declare a class in a header file and define its member functions separately, in a separate source file. How do you split a class that is declared as a namespace member into two or more source files? In the following header file Foo.hpp, I defined a namespace called NS that contains a declaration of class Foo:
//Foo.hpp namespace NS { class Foo {
public: void f(); void g(); }; }//close NS Then, in a separate source file called Foo.cpp, I first #include the header file Foo.hpp and define Foo's member functions f() and g():
//Foo.cpp #include "Foo.hpp" void NS::Foo::f() { /*..*/ }
void NS::Foo::g() { /*..*/ } To refer to a namespace member, you need to use the member's fully qualified name. The fully qualified name of class Foo is NS::Foo. So that the compiler knows that NS is a namespace name, the header file Foo.hpp must be #included before any reference to it is made. Extending a Namespace Namespaces are extensible. You may add more members to the same namespace in other .hpp files, as in the following example:
//Bar.hpp namespace NS //extends NS { class Bar { public: void a(); void b(); }; } Alternatively, you can forward declare the class in the namespace and then define it in a separate file:
namespace NS //extends NS { class Bar; //fwd declaration
}
class NS::Bar //definition of //previously declared class { public: void a(); void b(); }; Then, in the file Bar.cpp you define the newly-added class's member functions as follows:
#include "Bar.hpp" void NS::Bar::a() {/*..*/}
void NS::Bar::b() {/*..*/} Now both Foo and Bar are members of namespace NS. The compiler and the linker are able to identify these classes as members of the same namespace, although they appear in separate headers. Note that you cannot extend a namespace simply by using a fully qualified name of a new member of an existing namespace. In other words, even if namespace NS has been declared elsewhere and its declaration is visible to the compiler (e.g., because its header file was #included), the following code is ill-formed:
#include "Bar.hpp" //namespace NS is now visible class NS::C //Error, C hasn't been declared // explicitly as a member of NS { public: void a(); void b(); }; To fix this code, you have to explicitly declare C as a member of namespace NS before defining it. Now the question is: how do you use these classes in an application? Referring to a namespace member Inside the main.cpp file, you first have to #include the header files that declare Foo and Bar. Then, then add appropriate using-declaration:
#include "Bar.hpp" #include "Foo.hpp" int main() { using NS::Bar; //a using declaration using NS::Foo; //ditto Bar b; Foo f; f.f(); //... }
Namespaces interact with other features of the language and affect programming techniques. They make some features in C++ superfluous or undesirable, as I will show below. Using the Scope Resolution Operator In some frameworks, it's customary to add operator :: before a function's name to mark it explicitly as a function that is not a class member. For example:
void C::fill (const char * source) { ::strcpy (this->pbuf, source); } This practice is not recommended, though. Many of the standard functions that used to be global are now declared in namespaces. For example, strcpy now belongs to namespace std, as do most of the Standard Library's functions. Preceding a :: to these functions might confuse the compiler's lookup algorithm and mislead human readers. Therefore, either use the function's fully qualified name or use an appropriate using-declaration to refer to such a function. Using static to Indicate Internal Linkage In standard C, a nonlocal identifier declared static has internal linkage, which means that it's accessible only from the translation unit in which it is declared (linkage types are discussed in the section "Memory Management"). This technique is used to support information hiding as in the following sample:
//File hidden.c //invisible from other files */ static void decipher(FILE *f);
decipher ("passwords.bin");
//end of file Although this convention is still supported in C++, it's now considered deprecated. This means that future releases of your compiler might issue a warning message if you declare a nonlocal variable static. To make a function accessible only from within its translation unit, use an unnamed namespace instead. You should do that, for instance, when you migrate from C. For example:
//File hidden.cpp
namespace //anonymous { void decipher(FILE *f); } // now use the function in hidden.cpp. //No using declarations or directives are needed decipher ("passwords.bin"); Members of an anonymous namespace can never be seen from any other translation unit, so the net effect is as if they had static linkage. If you declare another function with the same name in an unnamed namespace in another file, the two functions will not clash. Standard header files All Standard C++ header files now have to be #included in the following way:
#include //note: no ".h" extension The former ".h" extension was omitted from the headers' names. This convention also applies to the standard C header files, with the addition of the letter 'c'affixed to their name. Thus, a C standard header formerly named is now . For example:
#include //formerly: Although the older convention for C headers, such as , is still supported, it's now considered a deprecated feature and should not be used in new C++ code. The problem is that C headers inject their declarations into the global namespace. In C++, on the other hand, most standard declarations are declared in namespace std and so are the standard C headers. Recall that you need a usingdeclaration, a using-directive, or a fully qualified name to access the declarations in the new style standard headers:
#include using std::printf;
void f() { printf("Hello World"); }
Summary Namespaces are an efficient and rather intuitive means of avoiding name conflicts. C++ offers three methods for injecting a namespace constituent into the current scope. The first is a using-directive, which renders all of the members of a namespace visible in the current scope. The second is a using-declaration, which is more selective and enables the injection of a single component from a namespace. Finally, a fully qualified name uniquely identifies a namespace member. While most programmers are familiar with the constructs of bringing an existing namespace member into scope, it's important to know how to define your own namespaces and how to declare its members correctly. You can always extend an existing namespace by adding new members to it. The new members needn't be declared within the pair of { and } of the original namespace declaration. However, it's advisable to group all namespace members' declarations within the same physical file for maintenance and documentation purposes. The argument-dependent lookupcaptures the programmer's intention without forcing him or her to use wearying references to a namespace.
All the time and date functions and data structures are declared in the standard header ( in). Time is represented as a positive integer of type time_t that contains the number of seconds elapsed since the epoch, or January 1st, 1970, 00:00 GMT. time_t is a platform-defined signed integral type containing at least 32 bits. As large as this type may seem, on 32-bit architectures time_t will roll over on January 18, 2038. Fortunately, hardware architectures are gradually switching to a 64-bit time_t, which can represent billions of years. The function time() retrieves the current calendar time from the system's clock. It has the following prototype:
time_t time(time_t * tp); In systems in which no clock is available, the function returns -1. If tp is not null, the value is also written to *tp. The following program retrieves the current time and displays it in its raw format:
#include using namespace std; int main() { time_t curr=time(0); cout << "current time is: " << curr <
char * ctime(const time_t * tp); This function returns a null-terminated string of the form:
Wed Jan 31 01:51:25 2001\n\0 To break the time into individual constituents such as year, month, and day of the week, use the tm struct:
struct tm
{ int tm_sec; //seconds after the minute (0-61) int tm_min; //minutes after the hour (0-59) int tm_hour; //hours since midnight (0-23) int tm_mday; //day of the month (1-31) int tm_mon; // months since January (0-11) int tm_year; // elapsed years since 1900 int tm_wday; // days since Sunday (0-6) int tm_yday; //days since January 1st (0-365) int tm_isdst; //1 if daylight savings is on, zero if not, //-1 if unknown }; Remember: the key to manipulating date and time is knowing how to convert time_t to tm and vice versa. To fill a tm struct with the local time, use the function localtime():
struct tm* localtime (const time_t *pt); localtime() takes a pointer to a valid time_t object, converts it to a local static tm struct and returns its address. Note that subsequent invocations of localtime() override the previous value of its local static tm object. Therefore, you should copy the result immediately to your own tm object. The following program fills a tm object with the current local time: #include using namespace std; int main() { time_t curr; tm local; time(&curr); // get current time_t value local=*(localtime(&curr)); // dereference and assign } To convert a tm struct to time_t, use the mktime() function:
time_t curr; tm local; time(&curr); // get current time_t value local=*(localtime(&curr)); // dereference and assign time_t temp=mktime(&local); // temp and curr are equal
To compute the time difference between two dates, use the standard function difftime():
double difftime (time_t t1, time_t t2); This function takes two variables of type time_t and returns t2-t1 expressed in seconds. For example:
time_t now=time(0); time_t last_week=now-(60*60*24*7); // a week ago double seconds=difftime(now, last_week); To calculate time zone differences, use the gmtime() function:
struct tm * gmtime(const time_t * tp); gmtime() converts the calendar time into its GMT equivalent. The following code calculates the difference between your local time zone and GMT:
time_t curr=time(0);// current local time tm local=*gmtime(&curr);// convert curr to GMT, store as tm time_t utc=(mktime(&local));// convert GMT tm to GMT time_t double diff=difftime(utc,curr)/3600; //difference in hours NOTE The term Greenwich Mean Time (GMT) was changed to Universal Time Coordinated (UTC) several years ago but GMT is still widely used in the literature and more importantly, it's used in the Standard Library's function names. The library provides the building bricks of time retrieval, processing and formatting. Using this library instead of any other proprietary library offers three major benefits: portability, efficiency and minimal memory and speed overhead. For more advanced uses, you can find useful open source utilities that implement timers and progress bars that are based on the library such as the Boost time and date library. C traditionally associates three file descriptors—small positive integers—with each program: stdin, stdout, and stderr, which represent the standard input, standard output, and standard error, respectively. Although these descriptors are typically mapped to I/O devices such as a keyboard and a monitor, they're treated as files. This convention stems from the fact that C was originally developed on UNIX. UNIX treats every I/O source as a file, even when referring to physical devices such as a keyboard or a screen. C++ replaced the vintage library of standard C with an object-oriented stream library called . In addition, the Standard Library provides the library for string-based I/O and the library for file I/O. The notion of streams refers to any form of data represented as a sequence of bytes that come from a certain source, such as a keyboard, a file, or a network connection. The most common stream objects are cin and cout, which represent the standard input and standard output, respectively. In addition, C++ defines two more stream objects: cerr and clog. cerr is an object that directs output to the standard error device. In most cases this is the user's screen, although certain systems use a dedicated console or a log file. clog is pretty similar to cerr except that it can use buffered I/O, whereas cerr doesn't. (I'll discuss buffered I/O shortly.) Note that all these streams are real objects, not classes. However, unlike with other user-defined classes, you don't have to instantiate them manually. C++ automatically creates these objects in the program's startup code so you can use them directly if your program #includes the header. For example:
#include int main()
{ std::cout<<"hello world!"< objects are declared in std namespaces. (For further information on namespaces, see the "Namespaces" section.) NOTE The four stream objects cin, cout, cerr, and clog also have wide-char equivalents: wcin, wcout, wcerr, and wclog. The std::endl part of the code above is of special interest. (By the way, it's pronounced end ell; the last character is the lowercase letter L, not the number 1.). It's a manipulator; that is, an argument that affects the I/O operation is a certain way. The endl manipulator, for example, has two effects:
• •
It forces output flushing, meaning that it causes cout to output its buffered contents immediately. It appends a line break after the output operation.
Thus, the next cout statement will display its content on the next line. As previously mentioned, some iostream objects use buffered I/O. This means that they're allowed to lump several I/O operations and perform them at once. For example, the following statements may not be performed as three consecutive operations:
std::cout<<"hello"; std::cout<<" "; std::cout<<"world!"; Instead, the implementation may delay the output to the screen for efficiency reasons, and display the three strings in one shot. This buffering isn't always desirable. For example, if you're designing an interactive application that prompts the user to insert a password, you certainly don't want the user to wait indefinitely until the system decides to flush cout and display the prompt onscreen. The endl manipulator overrides this behavior and causes the output to be displayed without a delay:
std::cout<<"dear user, "; std::cout<<"please enter your password: "<
std::cout<<"dear user, "; std::cout<<"please enter password: "; //OK, no endl std::cin>>pwd; //at this point, cout has been flushed std::cout<<"your password has been read"<
The first two cout operations complete before the cin statement reads the user's password. Likewise, the cin operation completes before the last cout statement takes place. The library defines a rich set of format flags. These flags enable you to control the width, alignment, precision, and so on for the displayed data. Here's a list of these flags: Flag
Description
Example
skipws
skip whitespace on input
left
pad before value
" 100"
right
pad after value
"100 "
internal
pad between sign and value
"+ 120"
boolalpha
display true and false instead of 1 and 0
dec
base 10 output
109
hex
base 16 output
0xfad2
oct
base 8 output
0766
scientific
floating-point notation
ddd.ddEdd
fixed
fixed decimal notation
dd.ddd
showbase
prefix oct with 0 and hex with 0x
showpoint
print trailing zeros
showpos
show + for positive integers
uppercase
use E, X instead of e, x
String Streams The library includes set of classes for string-based I/O, enabling you to convert between datatypes automatically and safely. The ostringstream, istringstream, and stringstream char-oriented specializations perform output, input and combined input and output formatting, respectively. Each of these classes has a matching wchar version: wostringstream, wistringstream, and wstringstream, respectively. Type Conversions In C++, certain type conversions are implicit, such as long to double, signed to unsigned, and base* to derived*. However, to convert strings to numbers and vice versa, you have to use explicit conversion functions. C-style programs usually allocate a static buffer to store the result and call an appropriate conversion function from the library, e.g., atoi(), sprintf(), or sscanf(). This technique, though still popular in many projects and frameworks, is a fertile source of bugs and security loopholes:
• •
Buffer overflow. If the target buffer is too small to store the result, the conversion function might write past the buffer boundaries, causing undefined behavior. Crackers often exploit such insecure function calls to crash a process or to break into a remote computer. Lack of type safety. The stdio conversion functions have no type checking mechanism. As a result, programs using an incorrect format flag result in undefined behavior.
Clearly, you want to avoid style conversions. Use the type-safe, generic, and secure library instead. Insertion and Extraction A stringstream-based conversion consists of writing the value to a stringstream object and extracting it in as a different type. The stringstream object automatically performs the low-level conversion of the source type to string when you insert a value to it. When you extract a value from the stringstream object and write it to the target variable, the opposite conversion takes place. NOTE
The library supersedes the pre-standard and deprecated library, which includes the strstreambuf, istrstream, ostrstream and strstream classes. However, some older compilers support only the latter. The following code listing defines a stringstream object and inserts a variable of type double to it. The library usees the overloaded << and >> operators for insertion and extraction, as do all standard stream libraries:
#include using namespace std; int main() { double d=123.456; stringstream s; s << d; // insert d into s } The classes manage their memory automatically, allocating more storage as needed, and releasing it when the stream object is destroyed. This eliminates the risk of buffer overflows and memory leaks which are so common with conversions. To convert the value stored in s to a string, use the >> operator, like this:
string val; s >> val; //convert 123.456 to a string and write it to val Now val contains "123.456". The opposite conversion of double to string is trivial:
string val="124.55"; stringstream s; double d=0; s << val; // insert string s >> d; // d now equals 124.55 Generic Conversions
stringstream-based conversion uses the same sequence of operations regardless of the actual type being converted. Consequently, it's easy to write generic conversion functions that are based on objects: Our first conversion template takes a value of an arbitrary type T, converts it to string and writes the result to the user-supplied string val. The stringstream::str() member function is used for obtaining a copy of the stream's internal string:
#include #include using namespace std; template < typename T>
void string_format(string & val, const T & t) { ostringstream oss; oss << t; val=oss.str(); // extract string and assign it to val } The following example uses the string_format() template to convert the value 15.76 to string and write the result to val:
string val; string_fmt(val,15.76); cout<
template out_type stream_cast(const in_value & t) { stringstream ss; ss << t; out_type result; ss >> result; return result; } Here, stream_cast() converts the string "18.99" to double:
string s="18.99"; double d=stream_cast (s); // assign 18.99 to d The library provides a set of classes that perform file I/O. This library is a replacement for the standard C library. The library includes the ifstream, ofstream, and fstream classes for input file operations, output file operations, and combined input and output operations, respectively. Each of these classes also has a wide-char equivalent: wifstream, wofstream, and wfstream, respectively. The ifstream class supports the overloaded >> operator. Likewise, ofstream supports the << operator. fstream combines input and output operations; it therefore overloads both the >> and << operators. The following program creates an ifstream object called dictionary and prints each word in it onscreen:
#include #include
#include #include using namespace std; int main() { string s; cout<<"enter dictionary file: "; cin>>s; //fstream's ctor accepts only char * filenames ifstream dictionary (s.c_str()); if (!dictionary) // were there any errors on opening? exit(-1); while (dictionary >> s) cout << s <<'\n'; } The call to the string::c_str() member function is required because objects accept only const char * filenames. When you pass a filename as an argument, the constructor attempts to open that file. Next, the overloaded ! operator checks the file's status. If an error has occurred, the operator evaluates as true. The last line contains a loop that, on each iteration, reads a word from the file, copies it to s, and displays it. Note that the program doesn't check for an EOF character explicitly, because the overloaded >> operator handles this condition automatically. Furthermore, it doesn't close the file explicitly; the destructor does that automatically. The , , and libraries are closely related. They contain classes derived from a common set of abstract I/O classes that define the basic interface of C++ I/O. Each of these libraries defines a specialized form of I/O: screen I/O, string I/O, and file I/O, respectively. The objectoriented interface of these libraries simplifies their usage immensely. Thus, instead of opening and closing a file manually, you simply pass a filename as an argument to an ifstream object and let it take care of the rest. A common complaint from programmers who are used to the library is that C++ streams don't offer the same level of finely tuned format flags. This claim is incorrect, however. C++ offers a rich set of flags and manipulators that offer the same functionality. Two of the main advantages of the C++ stream libraries is their type-safety and extensibility. It's easy to extend these classes and define additional overloaded member functions and operators such as <<, >>, etc. to support user-defined types. Despite a common belief to the contrary, object-oriented programming isn't new. Back in the late 1960s, the Modula programming language already implemented many of the principles of this paradigm. Smalltalk, which appeared in 1972, was the first pure object-oriented language. Unlike other languages, it enforced— rather than enabled—strict object-oriented practices. Although Smalltalk never gained much popularity, it inspired many other programming languages such as Eiffel and Java (but not C++), which adopted its object model. The primary data abstraction mechanism in OO programming languages is a class. A class is a userdefined type that represents an object or a concept—a file, a hardware device, a database record, a document, an airplane, etc. An object is an instance of a class, just like a variable in procedural programming languages is an instance of a type. Before we continue our discussion, let's look at the principles of object-oriented programming and see how they're implemented in C++. The six major criteria are as follows:
• •
Abstract datatyping Information hiding
• • • •
Encapsulation Inheritance Polymorphism Dynamic binding
Programming languages that support abstract datatyping (ADT) allow programmers to extend the language's set of built-in types by adding user-defined types that are treated as first-class citizens. In C++, the most prevalent form of this is concrete classes such as string, vector, list, and so on. However, ADT isn't confined to classes. C++ also enables you to declare structs, unions, enum types, and typedef names that behave as native types. While it's true that structs, unions, and enum types also exist in C, they're not considered first-class citizens in this language. The following C snippet demonstrates the difference:
enum Traffic_light{ red, yellow, green}; int val; enum Traffic_light t; /* enum must be used in C*/ When you create an enum variable in C, you must include the keyword enum before the enumeration's typename. The same is true for structs and unions. Writing something like this:
Traffic_light t; is allowed only with typedefs. In C++, this restriction doesn't exist:
int val; Traffic_light t; // allowed in C++ Abstract datatyping enables programmers to extend and perfect the limited set of built-in types available in their programming languages. String classes are a good example of this. Although C++ doesn't have a builtin string type, the C++ Standard Library provides a string class that remedies this lack. Information hiding is manifested by enabling programmers to restrict access to certain data and code. This way, a class may prevent other classes and functions from accessing its data members and some of its member functions, while allowing them to access its non-restricted members. Let's look at a concrete example. Suppose we have a Time class that counts the time of day:
class Time { public: void Display(); private: int ticks; }; The Display() member function prints the current time onscreen. This member function is accessible to all. It's therefore declared public. By contrast, the data member ticks is declared private. Therefore, external users can't access it. Only Time's member functions are allowed to access it. In other words, the type of ticks; its current value; and, in fact, its very existence are pieces of information that we want to hide because these are all implementation details. What's so special about implementation details that object-oriented languages strive so hard to hide them? The main problem with exposing such details is that they're likely to change in the future. If these details were indiscriminately accessible to all, the result would be a maintenance nightmare because every change in an implementation detail would propagate to every piece of code that depends on that detail. For example, if we decide to store the current time as the number of CPU cycles rather than the number of the system's clock ticks, every piece of code that relied on the previous representation would break. By contrast, the public members of a class are its interface. Interfaces
are less likely to change. Regardless of how Display() extracts the current timestamp from ticks, users can be sure that it will "do the right thing" and display the correct time onscreen. In addition to private and public, C++ has a third access-specifier: protected. Protected members of a class are accessible to its members as well as to members of classes derived from it. However, they are inaccessible to any other classes or functions. I'll discuss this in further detail in the section "Inheritance." Encapsulation is often confused with information hiding. However, these terms are not interchangeable. Encapsulation is the ability to bundle related data and functionality within a single, autonomous entity called a class. For example, a class called LoggerFile might bundle data members such as the log file's path; a buffer of data waiting to be written to that file; and member functions that open, read, write, and close that file, as in the following code listing:
class LogFile { public: int Open(); int Read(char *buff); int Write(const char *buff); int Close(); private: FILE *logfile; bool _open; //...additional data members }; In procedural languages such as C, you declare these data members and the associated functions separately. Consequently, a global function that opens a log file may be mistakenly called to open a file that has already been opened. Worse yet, users might delete a log file and then attempt to write to it. By bundling the data and functionality in an autonomous class, it's much easier to avert such human errors, because the class maintains the state of the file and is therefore able to prevent such errors. Inheritance is the flagship of object-oriented programming. It enables you to derive more specialized classes from another class—a base class. Derivation enables a derived class to inherit the functionality of the base class and extend it or alter only specific parts of it. The main advantage of derivation is code reuse. Suppose we want to create a new LogFile class that performs periodic backups of data. Instead of writing all the functionality of a log file class from scratch, we can derive the new class from LogFile and add the necessary data members and functions to it:
class BackupLogFile: public LogFile { public: int Backup(); private: time_t previous_backup; };
Notice that the programmer only had to declare the additional functionality. Inheritance, of course, isn't limited. You can derive another class from BackupLogFile, say NetBackupLogFile, that enables the system manager to monitor the backup process from a remote web browser. C++ is one of the few OO programming languages that support multiple inheritance (MI), whereby a class inherits from two or more base classes simultaneously. While many OO critics claim that MI is dangerous and complicates the language unnecessarily, it's hard to ignore its power. Consider a multimedia player class. Usually, such media players consist of two major components: an audio player and a video player. Deriving a multimedia player from these classes seems like a natural choice:
class MediaPlayer: public AudioPlayer, public VideoPlayer { public: int Play(); //... }; The use of MI in this case reflects the symmetric nature of a multimedia player better than a single inheritance model. This is all well and good, but MI might incur complexities. In the previous example, we didn't look at the definitions of classes AudioPlayer and VideoPlayer. In well-designed OO projects, it's likely that these classes are derived from other classes as well. And if both of them happen to derive from the same class, we could get into trouble:
class DataCompressor { public: void CompressStream(); void DecompressStream(); //... }; class AudioPlayer :public DataCompressor { //... }; class VideoPlayer :public DataCompressor { //... }; Can you see what can go wrong with this? AudioPlayer and VideoPlayer each contain a distinct copy of DataCompressor. MediaPlayer inherits from these two classes and consequently gets two copies of DataCompressor, one from each base class. This duplication results in ambiguity when MediaPlayer objects try to invoke member functions of DataCompressor. For example:
MediaPlayer player;
//..load a clip player.DecompressStream();// ambiguous call While it's possible to resolve this ambiguity by using a qualified name of the member function in question, this is still a nuisance. To avoid such ambiguities, you use virtual inheritance. Regardless of the derivation lattice, there's always a single instance of a virtual base class in its derived classes. For example:
class AudioPlayer : virtual public DataCompressor {...}; class VideoPlayer : virtual public DataCompressor {...}; class MediaPlayer: public AudioPlayer, public VideoPlayer {...}; Now MediaPlayer has only a single instance of DataCompressor. DecompressStream() is therefore unambiguous. Virtual inheritance affects the order of the construction of base classes in a derived class. To ensure that only a single instance of a virtual sub-object exists in a derived class, virtual base classes are constructed before non-virtual base classes. Polymorphism is another elusive term. Many programmers confuse it with dynamic binding, which I'll discuss shortly. However, dynamic binding is only one of three manifestations of polymorphism in C++. The word polymorphism is composed of two Greek words that mean "multiple forms." In natural languages such as English, polymorphism is widely used. Consider the verb to open. Its exact interpretation depends on the object it takes. For example, opening a book, opening a door, and opening a conversation are three different actions. As a speaker of the language, you can tell the difference between these instances by examining the context and the objects that the verb takes. In programming languages, polymorphism refers to the object's ability to respond in an individual manner to the same message. Imagine a program that has a set of shape objects: square, triangle and trapezium. All these objects are derived from a common Shape base class, which has a member function called Draw(). When you call Draw() on a triangle, it reacts by drawing a triangle on the screen; calling Draw() on a square object causes it to draw a square on the screen, and so on. As you can see, the Draw() function behaves like the verb to open: Its exact interpretation depends on the object that it takes. Here again, programming languages separate between the interface (in this case, a member function called Draw() that causes a shape object to be drawn onscreen) and the implementation details (how exactly the Draw() operation is implemented in every object), which remain hidden from the users. This form of polymorphism is achieved by means of dynamic binding. However, C++ supports three more flavors of polymorphism: function overloading, operator overloading, and templates. I discuss each of these features in their relevant sections. However, I'll give a few examples here to demonstrate. The use of the += operator with integers or string objects, for example, is interpreted by each of these objects in an individual manner. Obviously, the underlying implementation of += differs for every type. Yet, intuitively, we can predict what the results will be. Templates are another example of polymorphism. A vector of integers and a vector of strings implement the push_back() member function differently, although the gory implementation details are hidden from the user:
vector names; vi.push_back( 5 ); names.push_back (string("James")); Dynamic Binding | Next Section Earlier, I explained how dynamic binding and polymorphism are related. However, I didn't explain how this relationship is implemented. Dynamic binding refers to the mechanism that resolves a virtual function call at
runtime. This mechanism is activated when you call a virtual member function through a reference or a pointer to a polymorphic object. Imagine a class hierarchy in which a class called Shape serves as a base class for other classes (Triangle and Square):
class Shape { public: void virtual Draw() {} //dummy implementation //.. }; class Square { public: void Draw(); //overriding Shape::Draw } class Triangle { public: void Draw(); //overriding Shape::Draw } Draw() is a dummy function in Shape. It's declared virtual in the base class to enable derived classes to override it and provide individual implementations. The beauty in polymorphism is that a pointer or a reference to Shape may actually point to an object of class Square or Triangle:
void func(const Shape* s) { s->Draw() } int main() { Shape *p1= new Triangle; Shape *p2 = new Square; func(p1); func(p2); } C++ distinguishes between a static type and a dynamic type of an object. The static type is determined at compile time. It's the type specified in the declaration. For example, the static type of both p1 and p2 is
"Shape *". However, the dynamic types of these pointers are determined by the type of object to which they point: "Triangle *" and "Square *", respectively. When func() calls the member function Draw(), C++ resolves the dynamic type of s and ensures that the appropriate version of Draw() is invoked. Notice how powerful dynamic binding is: You can derive additional classes from Shape that override Draw() even after func() is compiled. When func() invokes Draw(), C++ will still resolve the call according to the dynamic type of s. As the example shows, dynamic binding isn't confined to the resolution of member function calls at runtime; rather, it applies to the binding of a dynamic type to a pointer or a reference that may differ from its static type. Such a pointer or reference is said to be polymorphic. Likewise, the object bound to such a pointer is a polymorphic object. Dynamic binding exacts a toll, though. Resolving the dynamic type of an object takes place at runtime and therefore incurs performance overhead. However, this penalty is negligible in most cases. Another advantage of dynamic binding is reuse. If you decide to introduce additional classes at a later stage, you only have to override Draw() instead of writing entire classes from scratch. Furthermore, existing code will still function correctly once you've added new classes. You only have to compile the new code and relink the program Some of the six criteria that I've surveyed may be implementable in procedural programming languages as well, albeit with a significant effort and programmer's ingenuity. C++ automates and simplifies this immensely by means of keywords, strict type-checking, and state-of-the-art compiler technology. Remember that while all object-oriented programming languages adhere to these criteria, they differ radically in their underlying implementation. In Smalltalk, for instance, every type is a class, including characters, integers, and so on. C++, on the other hand, distinguishes between primitive types (also called built-in types or fundamental types) such as int and bool on the one hand, and classes on the other hand. This design decision isn't an omission: The creators of C++ attempted to keep it as efficient as C, and therefore needed to make certain compromises. While critics bemoan the fact that C++ is not a pure object-oriented language, its support of multiple programming paradigms is deliberate and fruitful; without this leeway, generic programming would be nearly impossible. Likewise, if C++ didn't support procedural programming, it wouldn't have become a widely used general-purpose programming language. That said, I believe I've shown here that C++ is even more objectoriented than other programming languages. For example, it's one of the few languages that support multiple inheritance, operator overloading, and templates. Notice how the term object-oriented has been misused throughout the years. From the criteria above, it's obvious that fancy GUI and point-and-click interfaces have little to do with this programming paradigm; in order to qualify as object-oriented, a programming language must meet the design criteria discussed here. In fact, if you carefully examine some of the frameworks, programming languages, and software tools that boast their alleged object-oriented approach, you'll discover that they aren't truly OO, because they don't comply with these design principles. Slowly but surely, state-of-the-art C++ programming is becoming less and less object-oriented. No, C++ isn't falling back to procedural programming -- quite to the contrary. However, if you examine standard C++ libraries (such as STL, , reference_warapper and just about any other recent addition to the language), you will notice that the traditional concepts of object-oriented programming have fallen from grace, replaced by more advanced paradigms and techniques. It wouldn't be an exaggeration to say that classic object-orientation is now a thing of the past. Today, I will discuss this paradigm shift and its causes. Traditional Object-Oriented Concepts The roots of object orientation date back to the late 1960s, when languages such as Modula-2 implemented dynamic binding, encapsulation, and inheritance. Later programming languages (particularly Smalltalk 72) refined these concepts, forming a new paradigm called "object-oriented programming." If anything, OOP focused on the ability to define autonomous units that bundle data and related operations as an object. Many of the early OO languages relied on dynamic typing: virtual functions, inheritance and the ability to pick and mix properties of multiple objects at runtime. As always, proponents of the new paradigm promised a higher level of code reuse, resilience to design changes, safety, reliability and portability. Indeed, if you compare antiquated programming languages such as Fortran and COBOL to Smalltalk, OO has fulfilled these promises to some extent. Yet today, more than a decade after the revolution that made OO a predominant programming paradigm, traditional OO programming is a disappointment. Diplomatic understatements and lip-service won't change this fact. Let's see why OO programming has lost its luster in C++.
Code Reuse Code reuse was OOP's biggest promise. Pundits claimed that by using virtual member functions and inheritance, you could get the ultimate level of code reuse while still benefiting from resilience to design changes. In practice, though, this software design model has resulted in a large number of extremely inefficient frameworks and libraries. Take MFC for example. Its set of collection classes is light years behind STL. The problem isn't with MFC, though. Similar frameworks, say OWL and National Institute of Health Class Library (NIHCL), repeated exactly the same design mistakes: deriving every collection class from an abstract collection class and relying on virtual member functions and dynamic typing. This suggests that OO itself is the culprit, not the designers. Member Functions Member functions (or methods, as they are called in other programming languages) are a fundamental aspect of OOP. Think for minute: What could be more logical and properly designed than a member function that is familiar with the intimate details of its object? Obvious advantages not withstanding, member functions are disfavored in state-of-the-art C++ libraries. The problem is that a member function is useful only for a single class. This is the bane of code reuse. Think, for example, of a library of containers. If each container class defines its own size() member function, you will end up writing numerous size() functions that basically do the same thing. The alternative is to define a generic function (let's call it an algorithm to make it more palatable for hard core OO aficionados) that works for every container type. Isn't this a step backwards into the good old days of procedural programming, where data structures and functions that manipulated them were kept apart? Syntactically speaking -- yes. Generic programming looks like procedural programming more than objectoriented programming. Yet under the hood, things work very differently. A generic algorithm, unlike a typical function in a procedural language, knows very little about the data structure it manipulates. Furthermore, it doesn't peek into the data structure directly but uses iterators for this purpose. So the syntactic similarity is misleading. Should member functions be thrown out of the window? Not quite. They are useful under the following conditions: when the language forces you to use a member function (constructors, destructors and conversion operators for example), or when the member function implements a service that is meaningful only in the context of a certain class. An example of this is a connect() member function of a socket class. In most other cases, experience has shown that common operations such as insert(), assign(), replace(), sort(), and copy() , which are applicable to a very wide set of objects, are best implemented as freestanding algorithms rather than being replicated as a member function in every class. Inheritance Another holy cow of traditional OO design is inheritance. STL hardly uses inheritance; it seems that the newer a C++ library is, the less it uses inheritance. Why? In theory at least, inheritance is the primary means of reuse. However, it incurs a lot of complications and overhead. First, every class hierarchy that relies on inheritance must have a virtual destructor and virtual functions. For certain abstractions, such as C++ streams, this model is used effectively. Yet, in other abstractions such as containers, there's little motivation to derive container classes from a common base class. Inheritance incurs another onerous problem: it propagates bugs. A faulty member function in a base class contaminates every derived class. Even if the base class' functions are bug-free, derived classes often carry the excess baggage inherited from their base classes. Look at cout, for example. How many programmers ever bother to use the numerous member functions that the ios_base and basic_ios base classes pass on to them? By forgoing inheritance, STL containers don't carry such excess baggage. Furthermore, the fact that every container class is independent enables implementers to optimize each of them. Conclusions One trick that OO diehards use is to broaden its definition. They claim that a through and through OO language should provide facilities for generic programming and functional programming in addition to the traditional OO concepts. Under this broad definition, the recent additions to the Standard Library still follow the OO model. However, this is just a verbal maneuver that is meant to camouflage the real facts: OO in its
classic sense is a thing of the past, at least in C++. Experience has shown that generic programming and to a smaller extent, functional programming, achieve a high level of code reuse, portability and efficiency. Books Exceptional C++ Style, by Herb Sutter, contains a systematic analysis of class std::string. Sutter shows that the majority of its member functions can actually be replaced with existing STL algorithms, at least in theory. He also provides plenty of reasons why this approach is better. The four mini-chapters dedicated to this issue are indispensable for anyone who is interested in learning how general purpose libraries should be designed today. It's surprising to see that the original notions of OOP such as inheritance, virtual functions and member functions have become so antiquated and cumbersome in the last 10 years. Undoubtedly, were class std::string to be re-designed from scratch today, it would offer a cleaner, slimmer and more consistent interface The generic programming paradigm is meant to enable a higher level of code reuse than traditional objectoriented programming. Instead of relying on inheritance and polymorphism, it relies on type independence. C++ has two features that support this paradigm: templates and operator overloading. A combination of these features allows a generic algorithm to assume very little about the actual object to which it's applied, whether it's a fundamental type or a user-defined type. Consequently, such an algorithm offers a higher reusability potential than does a type-dependent algorithm. The Standard Template Library (STL) is an exemplary framework built on the foundations of generic programming. STL is a collection of generic algorithms and containers that communicate through iterators, which are pointers or pointer-like constructs. A complete account of every STL container and algorithm can fill a book of its own. (Several excellent books on the topic have been published in recent years; see the recommendations in the resources sections.) Therefore, this section only discusses the basic concepts of generic programming, starting with an overview of STL header files, and then moving on to containers, iterators, algorithms, function objects, adaptors, and allocators. Finally, I describe the class std::string STL components are defined in the following header files:
•
Containers. Container classes are defined in the header files shown in the following table. The associative containers multimap and multiset are defined in 
