The most usual way to start gdb is with one argument, specifying an executable program:
gdb program
You can also start with both an executable program and a core file specified:
gdb program core
You can, instead, specify a process ID as a second argument, if you want to debug a running process:
gdb program 1234
would attach gdb to process 1234.
You can optionally have gdb pass any arguments after the executable file to the inferior using —args. This option stops option processing.
gdb —args gcc -O2 -c foo.c

To exit gdb, use the quit command (abbreviated q), or type an end-of-file character (usually Ctrl-d). If you do not supply expression, gdb will terminate normally; otherwise it will terminate using the result of expression as the error code.

An interrupt (often Ctrl-c) does not exit from gdb, but rather terminates the action of any gdb command that is in progress and returns to gdb command level. It is safe to type the interrupt character at any time because gdb does not allow it to take effect until a time when it is safe.

If you need to execute occasional shell commands during your debugging session, there is no need to leave or suspend gdb; you can just use the shell command.
shell command-string Invoke a standard shell to execute command-string.
The utility make is often needed in development environments. You do not have to use the shell command for this purpose in gdb:
make make-args Execute the make program with the specified arguments. This is equivalent to ‘shell make make-args’.

Command Completion
you might want to set a breakpoint on a subroutine whose name begins with ‘make’, but when you type b
make_TAB gdb just sounds the bell. Typing TAB again displays all the function names in
your program that begin with those characters, for example:
(gdb) b make TAB
gdb sounds bell; press TAB again, to see:
make_a_section_from_file make_environ
make_abs_section make_function_type

gcc, the gnu C/C++ compiler, supports ‘-g’ with or without ‘-O’, making it possible
to debug optimized code. We recommend that you always use ‘-g’ whenever you compile
a program. You may think your program is correct, but there is no sense in pushing your
luck.

Use the run command to start your program under gdb. The arguments to your program can be specified by the arguments of the run command.
The ‘start’ command does the equivalent of setting a temporary breakpoint
at the beginning of the main procedure and then invoking the ‘run’ command.

attach process-id This command attaches to a running process—one that was started outside
gdb.The first thing gdb does after arranging to debug the specified process is to stop it.

When you have finished debugging the attached process, you can use the detach
command to release it from gdb control. Detaching the process continues its
execution.

On certain operating systems, gdb is able to save a snapshot of a program’s state, called
a checkpoint, and come back to it later.

Thus, if you’re stepping thru a program and you think you’re getting close to the point
where things go wrong, you can save a checkpoint. Then, if you accidentally go too far and
miss the critical statement, instead of having to restart your program from the beginning,
you can just go back to the checkpoint and start again from there.
This can be especially useful if it takes a lot of time or steps to reach the point where
you think the bug occurs.
checkpoint
Save a snapshot of the debugged program’s current execution state. The
checkpoint command takes no arguments, but each checkpoint is assigned
a small integer id, similar to a breakpoint id.
info checkpoints
restart checkpoint-id
delete checkpoint checkpoint-id

The most vexing parse is a specific form of syntactic ambiguity resolution in the C++ programming language.

class Timer {
 public:
  Timer();
};

class TimeKeeper {
 public:
  TimeKeeper(const Timer& t);

  int get_time();
};

int main() {
  TimeKeeper time_keeper(Timer());
  return time_keeper.get_time();
}

The line TimeKeeper time_keeper(Timer()); is ambiguous, since it could be interpreted either as

1. a variable definition for variable time_keeper of class TimeKeeper, initialized with an anonymous instance of class Timer or
2. a function declaration for a function time_keeper which returns an object of type TimeKeeper and has a single (unnamed) parameter which is a function returning type Timer (and taking no input).

Most programmers expect the first, but the C++ standard requires it to be interpreted as the second. One way to force the compiler to consider this as a variable definition is to add an extra pair of parentheses:TimeKeeper time_keeper( (Timer()) );

Using the new uniform initialization syntax introduced in C++11 solves this issue (and many more headaches related to initialization styles in C++). The problematic code is then unambiguous when braces are used:

TimeKeeper time_keeper{Timer{}};

class noncopyable
{
    protected:
        noncopyable() {}
        ~noncopyable() {}
    private:
        noncopyable(const noncopyable &orig);
        noncopyable & operator=(const noncopyable &rhs);
};

class A : private noncopyable
{
    public:
        A & operator=(const A &rhs) {} 
};

class B : private noncopyable
{};

int main()
{
    A a1,a2;
    B b1,b2;

    a1 = a2;  // ok
    b1 = b2;  // error
}

首先，构造函数和析构函数设置为protected，这样子类能够调用，但是却不能被外部调用。其次，拷贝构造函数和赋值运算符设置为私有的，并且只声明不实现。对于类A而言，它自己又实现了赋值运算符，并且在实现中它没有去调用父类的赋值运算符，所以是ok的。对于类B而言，它自己没有实现赋值运算符，那么编译器会自动合成一个，合成的赋值运算符会去调用父类的私有的赋值运算符从而导致编译失败。如果没有a1=a2这个语句，即没有需要赋值运算符的地方，则编译器不会为类A自动合成赋值运算符。

The common use of condition vars is something like:

thread 1:
    pthread_mutex_lock(&mutex);
    while (!condition)
        pthread_cond_wait(&cond, &mutex);
    /* do something that requires holding the mutex and condition is true */
    pthread_mutex_unlock(&mutex);

thread2:
    pthread_mutex_lock(&mutex);
    /* do something that might make condition true */
    pthread_cond_signal(&cond);
    pthread_mutex_unlock(&mutex);

1. pthread_cond_wait

pthread_cond_wait到底做了什么事情呢？
(1)释放mutex
(2)把当前线程加入到此条件变量的等待线程队列，然后睡眠
(3)当其他线程调用pthread_cond_signal或者pthread_cond_broadcast后，调用pthread_cond_wait的线程从睡眠状态醒来，然后试图重新获取mutex，如果此时能够获取mutex则从pthread_cond_wait返回，如果不能获取mutex则进入阻塞状态，等待其他线程释放mutex

其中，系统保证第一步和第二步是原子操作。为什么是原子操作呢？因为如果不是原子操作的话，会存在竞争条件(race condition)。当前线程释放mutex后，其他线程可以获得该mutex并调用pthread_cond_signal，然后当前线程再执行第二步，则会一直处于睡眠状态(直到其他线程再次调用pthread_cond_signal)，即错过了一次条件变量变为真的情况。

2. pthread_cond_signal

pthread_cond_signal does not unlock the mutex (it can’t as it has no reference to the mutex, so how could it know what to unlock?) In fact, the signal need not have any connection to the mutex; the signalling thread does not need to hold the mutex, though for most algorithms based on condition variables it will.

3. 线程1和线程2的并发执行情况

所以，线程1和线程2的并发执行情况是这样的:
(1)线程1获得mutex
(2)线程1测试条件为满足，则调用pthread_cond_wait，导致其释放mutex并把自己加入到条件变量的等待线程队列，然后睡眠
(3)线程2获得mutex
(4)线程2将条件设置为true，调用pthread|_cond_signal唤醒线程1，线程1被唤醒后，试图重新获取mutex，因为此时mutex被线程2持有，所以线程1被阻塞在获取mutex的操作上。
(5)线程2释放mutex
(6)线程1获得mutex，并从pthread_cond_wait返回。

4. pthread_cond_signal和pthread_mutex_unlock的顺序

我们看到线程2是先调用pthread_cond_signal，再释放mutex的。那么它们的执行顺序能反过来吗？答案是不能，因为反过来的话存在竞争条件。线程2在释放mutex后，线程1获取mutex，进行条件测试发现为false，于是线程1准备调用pthread_cond_wait。但就在此时，线程2执行pthread_cond_signal。之后，线程1再调用pthread_cond_wait导致其阻塞。即错过了一次条件变量变为真的情况。

5. 后记

A spin lock is like a mutex, except that instead of blocking a process by sleeping, the process is blocked by busy-waiting (spinning) until the lock can be acquired.

1. Pointer to Class Member

A pointer to member embodies the type of the class as well as the type of the member. Pointers to member apply only to non static members of a class. static class members are not part of any object, so no special syntax is needed to point to a static member. Pointers to static members are ordinary pointers.

class Screen {
    public:
        typedef std::string::size_type index;
        char get() const;
        char get(index ht, index wd) const;
    private:
        std::string contents;
        index cursor;
        index height, width;
};
## 2. Defining a Pointer to Data Member
string Screen::*ps_Screen = &Screen::contents;

普通指针使用*来标示，而指向类的成员函数的指针使用ClassName::*标示。需要注意的是，指向类的数据成员的指针并非指针，因为它既不包含地址，行为也不像指针。与常规指针不同，一个指向成员的指针并不指向一个具体的内存位置，它指向的是一个类的特定成员，而不是指向一个特定对象里的特定成员。通常最清晰的做法是将指向数据成员的指针看作 为一个偏移量 。 C++标准并没有说该如何实现指向成员的指针，大多数编译器都将指向数据成员的指针实现为一个整数，其中包含被指向成员的偏移量。另外加上1（加1是为了让0值可以表示一个空的数据成员指针）。 这个偏移量告诉你，一个特定成员的位置距离对象的起点有多少个字节。一个类成员的偏移量在任何对象中都是相同的。 为啥偏移量会加1呢？这主要用来区分“没有指向任何数据成员的指针”和“指向第一个数据成员的指针”这两种情况。考虑下面这样的例子：

float Point3d::*p1 =0;
float Point3d::*p2 = &Point3d::x;
 
if( p1 == p2 ){
    cout <<” p1 & p2 contain the same value.”;
    cout <<”they must address the same member!”<<endl;
}

3. Defining a Pointer to Member Function

A pointer to a member function must match the type of the function to which it points, in three ways:

• The type and number of the function parameters, including whether the member is const.
• The return type.
• The class type of which it is a member

  char (Screen::*pmf)() const = &Screen::get; char (Screen::*pmf2)(Screen::index, Screen::index) const; pmf2 = &Screen::get; typedef char (Screen::*Action)(Screen::index, Screen::index) const; Action get = &Screen::get;

4. Using a Pointer to Member Function

char (Screen::*pmf)() const = &Screen::get;
Screen myScreen;
char c1 = myScreen.get(); // call get on myScreen
char c2 = (myScreen.*pmf)(); // equivalent call to get
Screen *pScreen = &myScreen;
c1 = pScreen->get(); // call get on object to which pScreen points
c2 = (pScreen->*pmf)(); // equivalent call to get

5. Using a Pointer to Data Member

Screen::index Screen::*pindex = &Screen::width;
Screen myScreen;
// equivalent ways to fetch width member of myScreen
Screen::index ind1 = myScreen.width; // directly
Screen::index ind2 = myScreen.*pindex; // dereference to get width
Screen *pScreen;
// equivalent ways to fetch width member of *pScreen
ind1 = pScreen->width; // directly
ind2 = pScreen->*pindex; // dereference pindex to get width

6. Pointer-to-Member Function Tables

One common use for function pointers and for pointers to member functions is to store them in a function table. A function table is a collection of function pointers from which a given call is selected at run time.

class Screen {
    public:
        // other interface and implementation members as before
        Screen& home(); // cursor movement functions
        Screen& forward();
        Screen& back();
        Screen& up();
        Screen& down();
};

class Screen {
    public:
        // other interface and implementation members as before
        // Action is pointer that can be assigned any of the cursor movement members
        typedef Screen& (Screen::*Action)();
        static Action Menu[]; // function table
    public:
        // specify which direction to move
        enum Directions { HOME, FORWARD, BACK, UP, DOWN };
        Screen& move(Directions);
};

Screen& Screen::move(Directions cm)
{
    // fetch the element in Menu indexed by cm
    // run that member on behalf of this object
    (this->*Menu[cm])();
    return *this;
}

// What's left is to define and initialize the table itself:
Screen::Action Screen::Menu[] = {   &Screen::home,
                                    &Screen::forward,
                                    &Screen::back,
                                    &Screen::up,
                                    &Screen::down,
};

Screen myScreen;
myScreen.move(Screen::HOME); // invokes myScreen.home
myScreen.move(Screen::DOWN); // invokes myScreen.down

1. Run-Time Type Identification

RTTI is provided through two operators:

• The typeid operator, which returns the actual type of the object referred to by a pointer or a reference
• The dynamic_cast operator, which safely converts from a pointer or reference to a base type to a pointer or reference to a derived type

These operators return dynamic type information only for classes with one or more virtual functions. For all other types, information for the static (i.e., compile-time) type is returned. Dynamic casts should be used with caution. Whenever possible, it is much better to define and use a virtual function rather than to take over managing the types directly.

2. The dynamic_cast Operator

The dynamic_cast operator can be used to convert a reference or pointer to an object of base type to a reference or pointer to another type in the same hierarchy.

Unlike other casts, a dynamic_cast involves a run-time type check. If the object bound to the reference or pointer is not an object of the target type, then the dynamic_cast fails. If an dynamic_cast to a pointer type fails, the result of the dynamic_cast is the value 0. If a dynamic_cast to a reference type fails, then an exception of type bad_cast is thrown. The verification that the dynamic_cast operator performs must be done at run time.

if (Derived *derivedPtr = dynamic_cast<Derived*>(basePtr))
{
    // use the Derived object to which derivedPtr points
} else { // BasePtr points at a Base object
    // use the Base object to which basePtr points
}

Performing a dynamic_cast in a condition ensures that the cast and test of its result are done in a single expression. Another advantage is that the pointer is not accessible outside the if. If the cast fails, then the unbound pointer is not available for use in later cases where the test might be forgotten.

void f(const Base &b)
{
    try {
        const Derived &d = dynamic_cast<const Derived&>(b);
        // use the Derived object to which b referred
    } catch (bad_cast) {
        // handle the fact that the cast failed
    }
}

3. The typeid Operator

typeid(e) where e is any expression or a type name. When the operand is not of class type or is a class without virtual functions, then the typeid operator indicates the static type of the operand. When the operand has a class-type that defines at least one virtual function, then the type is evaluated at run time. The result of a typeid operation is a reference to an object of a library type named type_info.

Base *bp;
Derived *dp;
// compare type at run time of two objects
if (typeid(*bp) == typeid(*dp)) {
    // bp and dp point to objects of the same type
}
// test whether run time type is a specific type
if (typeid(*bp) == typeid(Derived)) {
    // bp actually points to a Derived
}

Note that the operands to the typeid are expressions that are objectswe tested *bp , not bp. Dynamic type information is returned only if the operand to typeid is an object of a class type with virtual functions. Testing a pointer (as opposed to the object to which the pointer points) returns the static, compile-time type of the pointer.

If the value of a pointer p is 0, then typeid(p) throws a bad_typeid exception if the type of p is a type with virtual functions. If the type of p does not define any virtuals, then the value of p is irrelevant. As when evaluating a sizeof expression the compiler does not evaluate p . It uses the static type of p , which does not require that p itself be a valid pointer.

1. A Memory-Allocator Base Class

One common strategy is to preallocate a block of raw memory to hold unconstructed objects. When new elements are created, they could be constructed in one of these preallocated objects. When elements are freed, we’d put them back in the block of preallocated objects rather than actually returning memory to the system. This kind of strategy is often known as maintaining a freelist . The freelist might be implemented as a linked list of objects that have been allocated but not constructed. We’ll define a new class that we’ll name CachedObj to handle the freelist.

The CachedObj class will have a simple interface: Its only job is to allocate and manage a freelist of allocated but unconstructed objects. This class will define a member operator new that will return the next element from the freelist, removing it from the freelist. The operator new will allocate new raw memory whenever the freelist becomes empty. The class will also define operator delete to put an element back on the freelist when an object is destroyed. Classes that wish to use a freelist allocation strategy for their own types will inherit from CachedObj.

As we’ll see, CachedObj may be used only for types that are not involved in an inheritance hierarchy. Unlike the member new and
delete operations, CachedObj has no way to allocate different sized objects depending on the actual type of the object: Its freelist holds objects of a single size. Hence, it may be used only for classes, such as QueueItem , that do not serve as base classes. The data members defined by the CachedObj class, and inherited by its derived classes, are:

• A static pointer to the head of the freelist
• A member named next that points from one CachedObj to the next

The next pointer chains the elements together onto the freelist. Each type that we derive from CachedObj will contain its own type-specific data plus a single pointer inherited from the CachedObj base class. When the object is in use, this pointer is meaningless and not used. When the object is available for use and is on the freelist, then the next pointer is used to point to the next available object.

The only remaining question is what types to use for the pointers in CachedObj. We’d like to use the freelist approach for any type, so the class will be a template. The pointers will point to an object of the template type:

template <class T>
class CachedObj
{
    public:
        CachedObj() : next(NULL) {}
        void * operator new(size_t);
        void operator delete(void *, size_t);
        virtual ~CachedObj() {}

    private:
        static void add_to_freelist(T*);
        static allocator<T> alloc_mem;
        static T *freeStore;
        static const size_t chunk;
        T *next;
};

The static members manage the freelist. These members are declared as static because there is only one freelist maintained for all the objects of a given type. The freeStore pointer points to the head of the freelist. The member named chunk specifies the number of objects that will be allocated each time the freelist is empty.

template <class T>
void * CachedObj<T>::operator new(size_t sz)
{
    // new should only be asked to build a T, not an object
    // derived from T; check that right size is requested

    if(sz != sizeof(T))
        throw runtime_error("CachedObj: wrong size object in operator new");

    if(NULL == freeStore)
    {
        T *array = alloc_mem.allocate(chunk);

        for(size_t i = 0; i < sz; ++i)
        {
            add_to_freelist(&array[i]);
        }
    }

    T *p = freeStore;
    freeStore = freeStore->CachedObj<T>::next;
    return p; // constructor of T will construct the T part of the object
}

template <class T>
void CachedObj<T>::operator delete(void *p, size_t)
{
    if(NULL != p)
        add_to_freelist(static_cast<T*>(p));
}

template <class T>
void CachedObj<T>::add_to_freelist(T *p)
{
    p->CachedObj<T>::next = freeStore;
    freeStore = p;
}

The only tricky part is the use of the next member. Recall that CachedObj is intended to be used as a base class. The objects that are allocated aren’t of type CachedObj . Instead, those objects are of a type derived from CachedObj . The type of T , therefore, will be the derived type. The pointer p is a pointer to T , not a pointer to CachedObj . If the derived class has its own member named next , then writing p->next would fetch the next member of the derived class! But we want to set the next in the base, CachedObj class.

What remains is to define the static data members:

template <class T> allocator< T > CachedObj< T >::alloc_mem;
template <class T> T *CachedObj< T >::freeStore = 0;
template <class T> const size_t CachedObj< T >::chunk = 24;

Here is how we use CachedObj:

class Screen: public CachedObj<Screen> {
    // interface and implementation members of class Screen are unchanged
};
template <class Type>
class QueueItem: public CachedObj< QueueItem<Type> > {
    // remainder of class declaration and all member definitions unchanged
};

2. 练习题

class iStack {
    public:
        iStack(int capacity): stack(capacity), top(0) { }
    private:
        int top;
        vector<int> stack;
};

(a) iStack *ps = new iStack(20);        // ok
(b) iStack *ps2 = new const iStack(15); // error
(c) iStack *ps3 = new iStack[ 100 ];    // error

注意iStack中类类型的数据成员stack的初始化方式。b错误是因为返回的是const iStack *类型的指针。c错误是因为使用new表达式动态分配数组时，如果数组元素具有类类型，则使用该类的默认构造函数初始化，但是iStack没有。

1. operator new and operator delete Functions

We have learned how to use the allocate class. Now we are using the more primitive library facilities. string * sp = new string("initialized"); Three steps actually take place. First, the expression calls a library function named operator new to allocate raw, untyped memory large enough to hold an object of the specified type. Next, a constructor for the type is run to construct the object from the specified initializers. Finally, a pointer to the newly allocated and constructed object is returned. When we use a delete expression to delete a dynamically allocated object: delete sp; Two steps happen. First, the appropriate destructor is run on the object to which sp points. Then, the memory used by the object is freed by calling a library function named operator delete.

The library functions operator new and operator delete are misleadingly named. Unlike other operator functions, such as operator= , these functions do not overload the new or delete expressions. In fact, we cannot redefine the behavior of the new and delete expressions. A new expression executes by calling an operator new function to obtain memory and then constructs an object in that memory. A delete expression executes by destroying an object and then calls an operator delete function to free the memory used by the object.

There are two overloaded versions of operator new and operator delete functions. Each version supports the related new and delete expression:

void *operator new(size_t); // allocate an object
void *operator new[](size_t); // allocate an array
void *operator delete(void*); // free an object
void *operator delete[](void*); // free an array

T* newelements = alloc.allocate(newcapacity);
// which could be rewritten as
T* newelements = static_cast<T*>(operator new[](newcapacity * sizeof(T)));

alloc.deallocate(elements, end - elements);
// which could be rewritten as
operator delete[](elements);

In general, it is more type-safe to use an allocator rather than using the operator new and operator delete functions directly.

2. Placement new Expressions

The library functions operator new and operator delete are lower-level versions of the allocator members allocate and deallocate. Each allocates but does not initialize memory. There are also lower-level alternatives to the allocator members construct and destroy. These members initialize and destroy objects in space allocated by an allocator object. Placement new allows us to construct an object at a specific, preallocated memory address. The form of a placement new expression is:

new (place_address) type
new (place_address) type (initializer-list)

alloc.construct(first_free, t);
// would be replaced by the equivalent placement new expression
// copy t into element addressed by first_free
new (first_free) T(t);

Placement new expressions are more flexible than the construct member of class allocator. When placement new initializes an object, it can use any constructor, and builds the object directly. The construct function always uses the copy constructor.

allocator<string> alloc;
string *sp = alloc.allocate(2); // allocate space to hold 2 strings
// two ways to construct a string from a pair of iterators
new (sp) string(b, e); // construct directly in place
alloc.construct(sp + 1, string(b, e)); // build and copy a temporary

The placement new expression uses the string constructor that takes a pair of iterators to construct the string directly in the space to which sp points. When we call construct, we must first construct the string from the iterators to get a string object to pass to construct. That function then uses the string copy constructor to copy that unnamed, temporary string into the object to which sp points.

3. Explicit Destructor Invocation

for (T *p = first_free; p != elements; /* empty */ )
    alloc.destroy(--p);
for (T *p = first_free; p != elements; /* empty */ )
    p->~T(); // call the destructor

The effect of calling the destructor explicitly is that the object itself is properly cleaned up. However, the memory in which the object resided is not freed. We can reuse the space if desired.

4. Class Specific new and delete

Another way to optimize memory allocation involves optimizing the behavior of new expressions. As an example, consider the Queue class from Chapter 16. That class doesn’t hold its elements directly. Instead, it uses new expressions to allocate objects of type QueueItem.

It might be possible to improve the performance of Queue by preallocating a block of raw memory to hold QueueItem objects. When a new QueueItem object is created, it could be constructed in this preallocated space. When QueueItem objects are freed, we’d put them back in the block of preallocated objects rather than actually returning memory to the system.

By default, new expressions allocate memory by calling the version of operator new that is defined by the library. A class may manage the memory used for objects of its type by defining its own members named operator new and operator delete.

When the compiler sees a new or delete expression for a class type, it looks to see if the class has a member operator new or operator delete . If the class defines (or inherits) its own member new and delete functions, then those functions are used to allocate and free the memory for the object. Otherwise, the standard library versions of these functions are called.

When we optimize the behavior of new and delete , we need only define new versions of the operator new and operator delete . The new and delete expressions themselves take care of constructing and destroying the objects. If a class defines either of these members, it should define both of them.

A class member operator new function must have a return type of void* and take a parameter of type size_t . The function’s size_t parameter is initialized by the new expression with the size, in bytes, of the amount of memory to allocate. A class member operator delete function must have a void return type. It can be defined to take a single parameter of type void or to take two parameters, a void and a size_t . The void* parameter is initialized by the delete expression with the pointer that was delete d. That pointer might be a null pointer. If present, the size_t parameter is initialized automatically by the compiler with the size in bytes of the object addressed by the first parameter.

The size_t parameter is unnecessary unless the class is part of an inheritance hierarchy. When we delete a pointer to a type in an inheritance hierarchy, the pointer might point to a base-class object or an object of a derived class. In general, the size of a derived-type object is larger than the size of a base-class object. If the base class has a virtual destructor, then the size passed to operator delete will vary depending on the dynamic type of the object to which the deleted pointer points. If the base class does not have a virtual destructor, then, as usual, the behavior of deleting a pointer to a derived object through a base-class pointer is undefined.

These functions are implicitly static members. There is no need to declare them static explicitly, although it is legal to do so. The member new and delete functions must be static because they are used either before the object is constructed ( operator
new ) or after it has been destroyed ( operator delete ). There are, therefore, no member data for these functions to manipulate. As with any other static member function, new and delete may access only static members of their class directly.

We can also define member operator new[] and operator delete[] to manage arrays of the class type. If these operator functions exist, the compiler uses them in place of the global versions.

A class member operator new[] must have a return type of void* and take a first parameter of type size_t . The operator’s size_t parameter is initialized automatically with a value that represents the number of bytes required to store an array of the given number of elements of the specified type.

The member operator delete[] must have a void return type and a first parameter of type void . The operator’s void parameter is initialized automatically with a value that represents the beginning of the storage in which the array is stored.

The operator delete[] for a class may also have two parameters instead of one, the second parameter being a size_t . If present, the additional parameter is initialized automatically by the compiler with the size in bytes of the storage required to store the array.

A user of a class that defines its own member new and delete can force a new or delete expression to use the global library functions through the use of the global scope resolution operator. If the user writes

Type *p = ::new Type; // uses global operator new
::delete p; // uses global operator delete

If storage was allocated with a new expression invoking the global operator new function, then the delete expression should also
invoke the global operator delete function.

1. Optimizing Memory Allocation

A common strategy is to preallocate memory to be used when new objects are created, constructing each new object in preallocated memory as needed. We need to decouple memory allocation from object construction. The obvious reason to decouple allocation and construction is that constructing objects in preallocated memory is wasteful.

In C++, When we use a new expression, memory is allocated, and an object is constructed in that memory. When we use a delete expression, a destructor is called to destroy the object and the memory used by the object is returned to the system. When we take over memory allocation, we must deal with both these tasks. When we allocate raw memory, we must construct object(s) in that memory. Before freeing that memory, we must ensure that the objects are properly destroyed. C++ provides two ways to allocate and free unconstructed, raw memory:

• The allocator class, which provides type-aware memory allocation. This class supports an abstract interface to allocating memory and subsequently using that memory to hold objects.
• The library operator new and operator delete functions, which allocate and free raw, untyped memory of a requested size.

C++ also provides various ways to construct and destroy objects in raw memory:

• The allocator class defines members named construct and destroy. The construct member initializes objects in unconstructed memory;
  the destroy member runs the appropriate destructor on objects.
• The placement new expression takes a pointer to unconstructed memory and initializes an object or an array in that space.
• We can directly call an object’s destructor to destroy the object. Running the destructor does not free the memory in which the object resides.
• The algorithms uninitialized_fill and uninitialized_copy execute like the fill and copy algorithms except that they construct objects in their destination rather than assigning to them.

// The behavior of copy template is equivalent to:
template<class InputIterator, class OutputIterator>
  OutputIterator copy (InputIterator first, InputIterator last, OutputIterator result)
{
  while (first!=last) {
    *result = *first;
    ++result; ++first;
  }
  return result;
}

也就是说copy是赋值行为，uninitialized_copy是在一块raw内存中的初始化行为。赋值行为意味着将释放原来的数据。Assigning to an object in unconstructed memory rather than initializing it is undefined. For many classes, doing so causes a crash at run time. Assignment involves freeing the existing object. If there is no existing object, then the actions in theassignment operator can have disastrous effects.

Modern C++ programs ordinarily ought to use the allocator class to allocate memory. It is safer and more flexible. However, when
constructing objects, the placement new expression is more flexible than the allocator::construct member. There are some cases where placement new must be used. 因为allocator::construct只能使用拷贝构造函数来构造对象。

2. The allocator Class

The allocator class separates allocation and object construction. When an allocator object allocates memory, it allocates space that is appropriately sized and aligned to hold objects of the given type. However, the memory it allocates is unconstructed. Users of allocator must separately construct and destroy objects placed in the memory it allocates.

3. Using allocator to Manage Class Member Data

To understand how we might use a preallocation strategy and the allocator class to manage the internal data needs of a class, let’s think a bit more about how memory allocation in the vector class might work.

// pseudo-implementation of memory allocation strategy for a vector-like class
template <class T> class Vector {
    public:
        Vector(): elements(0), first_free(0), end(0) { }
        void push_back(const T&);
        // ...
    private:
        static std::allocator<T> alloc; // object to get raw memory
        void reallocate();  // get more space and copy existing elements
        T* elements; // pointer to first element in the array
        T* first_free; // pointer to first free element in the array
        T* end; // pointer to one past the end of the array
        // ...
};

template <class T>
void Vector<T>::push_back(const T&t)
{
    if(first_free == end)
        reallocate();
    alloc.construct(first_free, t);
    ++first_free;
}

template <class T>
void Vector<T>::reallocate()
{
    ptrdiff_t size = first_free - elements;
    ptrdiff_t newcapacity = max(size, 1) * 2;
    T *new_elements = alloc.allocate(newcapacity);
    uninitialized_copy(elements, end, new_elements);

    for(T *p = elements; p != end; ++p)
        alloc.destroy(p);

    // deallocate cannot be called on a 0 pointer
    if (elements)
        alloc.deallocate(elements, size);

    elements = new_elements;
    first_free = elements + size;
    end = elements + newcapacity;
}

注意静态成员alloc在实现文件中的定义
template<class T>
allocator<T> Vector<T>::alloc;

Each Vector type defines a static data member of type allocator to allocate and construct the elements in Vectors of the given type. deallocate expects a pointer that points to space that was allocated by allocate. It is not legal to pass deallocate a zero pointer.

1. Multiple Inheritance

class Bear : public ZooAnimal { };
class Panda : public Bear, public Endangered { };

The constructor initializer controls only the values that are used to initialize the base classes, not the order in which the base classes are constructed. The base-class constructors are invoked in the order in which they appear in the class derivation list. For Panda , the order of base-class initialization is:

• ZooAnimal, the ultimate base class up the hierarchy from Panda ‘s immediate base clas Bear.
• Bear, the first immediate base class.
• Endangered, the second immediate base, which itself has no base class.
• Panda, the members of Panda itself are initialized, and then the body of its constructor is run.

Destructors are always invoked in the reverse order from which the constructors are run. In our example, the order in which the destructors are called is ~Panda, ~Endangered, ~Bear, ~ZooAnimal.

class X { ... };
class A { ... };
class B : public A { ... };
class C : private B { ... };
class D : public X, public C { ... };

which, if any, of the following conversions are not permitted?
D *pd = new D;
(a) X *px = pd; (c) B *pb = pd;
(b) A *pa = pd; (d) C *pc = pd;

b和c是错误的，因为C对B是私有继承的，对于C的子类而言，它完全不知道有B的存在，所有无法转化为B和A。

As is the case for single inheritance, if a class with multiple bases defines its own destructor, that destructor is responsible only for cleaning up the derived class. If the derived class defines its own copy constructor or assignment operator, then the class is responsible for copying (assigning) all the base class subparts. The base parts are automatically copied or assigned only if the derived class uses the synthesized versions of these members.

As usual, name lookup for a name used in a member function starts in the function itself. If the name is not found locally, then lookup continues in the member’s class and then searches each base class in turn. Under multiple inheritance, the search simultaneously examines all the base-class inheritance subtreesin our example, both the Endangered and the Bear / ZooAnimal subtrees are examined in parallel. If the name is found in more than one subtree, then the use of that name must explicitly specify which base class to use. Otherwise, the use of the name is ambiguous.

2. Multiple Base Classes Can Lead to Ambiguities

Assume both Bear and Endangered define a member named print . If Panda does not define that member, then a statement such as the following ying_yang.print(cout);results in a compile-time error. Although the ambiguity of the two inherited print members is reasonably obvious, it might be more surprising to learn that an error would be generated even if the two inherited functions had
different parameter lists. Similarly, it would be an error even if the print function were private in one class and public or protected in the other. Finally, if print were defined in ZooAnimal and not Bear, the call would still be in error. It’s because name lookup happens first. As always, name lookup happens in two steps: First the compiler finds a matching declaration (or, in this case, two matching declarations, which causes the ambiguity). Only then does the compiler decide whether the declaration it found is legal.

We could resolve the print ambiguity by specifying which class to use:ying_yang.Endangered::print(cout);. The best way to avoid potential ambiguities is to define a version of the function in the derived class that resolves the ambiguity.

3. Virtual Inheritance

class istream : public virtual ios { ... };
class ostream : virtual public ios { ... };
class iostream: public istream, public ostream { ... };

Members in the shared virtual base can be accessed unambiguously and directly. Similarly, if a member from the virtual base is redefined along only one derivation path, then that redefined member can be accessed directly. Under a nonvirtual derivation, both kinds of access would be ambiguous. Assume a member named X is inherited through more than one derivation path. There are three
possibilities:

• If in each path X represents the same virtual base class member, then there is no ambiguity because a single instance of the member is shared.
• If in one path X is a member of the virtual base class member and in another path X is a member of a subsequently derived class, there is also no ambiguitythe specialized derived class instance is given precedence over the shared virtual base class instance.
• If along each inheritance path X represents a different member of a subsequently derived class, then the direct access of the member is ambiguous.

4. Special Initialization Semantics

To solve the duplicate-initialization problem, classes that inherit from a class that has a virtual base have special handling for initialization. In a virtual derivation, the virtual base is initialized by the most derived constructor. Although the virtual base is initialized by the most derived class, any classes that inherit immediately or indirectly from the virtual base usually also have to provide their own initializers for that base. As long as we can create independent objects of a type derived from a virtual base, that class must initialize its virtual base. These initializers are used only when we create objects of the intermediate type.

Panda::Panda(std::string name, bool onExhibit) : ZooAnimal(name, onExhibit, "Panda"),
                                    Bear(name, onExhibit),
                                    Raccoon(name, onExhibit),
                                    Endangered(Endangered::critical),
                                    sleeping_flag(false) { }

When a Panda object is created:

• The ZooAnimal part is constructed first, using the initializers specified in the Panda constructor initializer list.
• Next, the Bear part is constructed. The initializers for ZooAnimal Bear’s constructor initializer list are ignored.
• Then the Raccoon part is constructed, again ignoring the ZooAnimal initializers.
• Finally, the Panda part is constructed.

If the Panda constructor does not explicitly initialize the ZooAnimal base class, then the ZooAnimal default constructor is used. If ZooAnimal doesn’t have a default constructor, then the code is in error.

5. Constructor and Destructor Order

Virtual base classes are always constructed prior to nonvirtual base classes regardless of where they appear in the inheritance hierarchy.

The immediate base classes are examined in declaration order to determine whether there are any virtual base classes. In our example, the inheritance subtree of BookCharacter is examined first, then that of Bear , and finally that of ToyAnimal. Each subtree is examined starting at the root class down to the most derived class.

The order in which the virtual base classes are constructed for TeddyBear is ZooAnimal followed by ToyAnimal. Once the virtual base classes are constructed, the nonvirtual base-class constructors are invoked in declaration order: BookCharacter, which causes the Character constructor to be invoked, and then Bear. Thus, to create a TeddyBear, the constructors are invoked in the following order:

ZooAnimal(); // Bear's virtual base class
ToyAnimal(); // immediate virtual base class
Character(); // BookCharacter's nonvirtual base class
BookCharacter(); // immediate nonvirtual base class
Bear(); // immediate nonvirtual base class
TeddyBear(); // most derived class

where the initializers used for ZooAnimal and ToyAnimal are specified by the most derived class TeddyBear. The same construction order is used in the synthesized copy constructor; the base classes also are assigned in this order in the synthesized assignment operator. The order of base-class destructor calls is guaranteed to be the reverse order of constructor invocation.

6. example1

class Class { ... };
class Base : public Class { ... };
class Derived1 : virtual public Base { ... };
class Derived2 : virtual public Base { ... };
class MI : public Derived1, public Derived2 { ... };
class Final : public MI, public Class { ... };

What is the order of constructor and destructor for the definition of a Final object?

Class()
Base()
Derived1()
Derived2()
MI()
Class()
Final()

将首先调用虚基类Base的构造函数(导致调用Class())。

7. example2

class Base {
    public:
        Base(std::string);
    protected:
        std::string name;
};

// 假设Base有上面的构造函数，则

class Derived1 : virtual public Base
{
    public:
        Derived1(std::string s) : Base(s) {}
};

class Derived2 : virtual public Base
{
    public:
        Derived2(std::string s) : Base(s) {}
};

class MI : public Derived1, public Derived2
{
    public:
        MI(std::string s) : Base(s), Derived1(s), Derived2(s) {}
};

class Final : public MI, public Class
{
    public:
        Final(std::string s) : Base(s), MI(s) {}
};

注意，任何直接或间接继承虚基类Base的类都要必须为Base类提供显示初始化式(例如MI、Final)，否则将无法创建相应类的对象。而且编译的时候还会有警告warning: direct base ‘Class’ inaccessible in ‘Final’ due to ambiguity

1.Classes, Namespaces, and Scope

When a name is used in a class scope, we look first in the member itself, then in the class, including any base classes. Only after exhausting the class(es) do we examine the enclosing scopes.

namespace A {
    int i;
    int k;
    class C1 {
        public:
            C1(): i(0), j(0) { } // ok: initializes C1::i and C1::j
            int f1()
            {
            return k; // returns A::k
            }
            int f2()
            {
            return h; // error: h is not defined
            }
            int f3();
        private:
            int i; // hides A::i within C1
            int j;
    };
    int h = i; // initialized from A::i
}
// member f3 is defined outside class C1 and outside namespace A
int A::C1::f3()
{
    return h; // ok: returns A::h
}

2. Argument-Dependent Lookup and Class Type Parameters

std::string s;
// ok: calls std::getline(std::istream&, const std::string&)
getline(std::cin, s);

It looks for a matching function in the current scope, the scopes enclosing the call to getline, and in the namespace(s) in which the type of cin and the string type are defined. Hence, it looks in the namespace std and finds the getline function defined by the string type.

3. Implicit Friend Declarations and Namespaces

Recall that when a class declares a friend function, a declaration for the function need not be visible. If there isn’t a declaration already visible, then the friend declaration has the effect of putting a declaration for that function or class into the surrounding scope. If a class is defined inside a namespace, then an otherwise undeclared friend function is declared in the same namespace:

namespace A {
    class C {
        friend void f(const C&); // makes f a member of namespace A
    };
}

void f2()
{
    A::C cobj;
    f(cobj); // calls A::f
}

4. Candidate Functions and Namespaces

Namespaces can have two impacts on function matching. One of these should be obvious: A using declaration or directive can add functions to the candidate set. The other is much more subtle. As we saw in the previous section, name lookup for functions that have one or more class-type parameters includes the namespace in which each parameter’s class is defined. This rule also impacts how we determine the candidate set. Each namespace that defines a class used as a parameter (and those that define its base class(es)) is searched for candidate functions. Any functions in those namespaces that have the same name as the called function are added to the candidate set. These functions are added even though they otherwise are not visible at the point of the call. Functions with the matching name in those namespaces are added to the candidate set:

namespace NS {
    class Item_base { /* ... */ };
    void display(const Item_base&) { }
}
// Bulk_item's base class is declared in namespace NS
class Bulk_item : public NS::Item_base { };
int main() {
    Bulk_item book1;
    display(book1);
    return 0;
}

5. Overloading and using Declarations

There is no way to write a using declaration to refer to a specific function declaration:

using NS::print(int); // error: cannot specify parameter list
using NS::print; // ok: using declarations specify names only

If a function is overloaded within a namespace, then a using declaration for the name of that function declares all the functions with that name. If there are print functions for int and double in the namespace NS, then a using declaration for NS::print makes both functions visible in the current scope.

If the using declaration introduces a function in a scope that already has a function of the same name with the same parameter list, then the using declaration is in error. Otherwise, the using declaration defines additional overloaded instances of the given name. The effect is to increase the set of candidate functions.

6. Namespaces and Templates

Declaring a template within a namespace impacts how template specializations are declared: An explicit specialization of a template must be declared in the namespace in which the generic template is defined. Otherwise, the specialization would have a different name than the template it specialized.

There are two ways to define a specialization: One is to reopen the namespace and add the definition of the specialization, which we can do because namespace definitions are discontiguous. Alternatively, we could define the specialization in the same way that we can define any namespace member outside its namespace definition: by defining the specialization using the template name qualified by the name of the namespace.

To provide our own specializations of templates defined in a namespace, we must ensure that the specialization definition is defined as being in the namespace containing the original template definition.

1. Namespaces

Unlike other scopes, a namespace can be defined in several parts. A namespace is made up of the sum of its separately defined parts; a namespace is cumulative. The separate parts of a namespace can be spread over multiple files. The fact that namespace definitions can be discontiguous means that we can compose a namespace from separate interface and implementation files. Thus, a namespace can be organized in the same way that we manage our own class and function definitions:

• Namespace members that define classes and declarations for the functions and objects that are part of the class interface can be put into header files. These headers can be included by files that use namespace members.
• The definitions of namepsace members can be put in separate source files.

Namespaces that define multiple, unrelated types should use separate files to represent each type that the namespace defines.

// ---- Sales_item.h ----
namespace cplusplus_primer {
    class Sales_item { /* ... */};
    Sales_item operator+(const Sales_item&, const Sales_item&);
}

// ---- Sales_item.cc ----
#include "Sales_item.h"
namespace cplusplus_primer {
    // definitions for Sales_item members and overloaded operators
}

It is also possible to define a namespace member outside its namespace definition. This definition should look similar to class member functions defined outside a class. The return type and function name are qualified by the namespace name. Once the fully qualified function name is seen, we are in the scope of the namespace. Thus, references to namespace members in the parameter list and the function body can use unqualified names to reference Sales_item.

cplusplus_primer::Sales_item
cplusplus_primer::operator+(const Sales_item& lhs, const Sales_item& rhs)
{
    Sales_item ret(lhs);
    // ...
}

Although a namespace member can be defined outside its namespace definition, there are restrictions on where this definition can appear. Only namespaces enclosing the member declaration can contain its definition. For example, operator+ could be defined in either the cplusplus_primer namespace or at global scope. It may not be defined in an unrelated namespace.

2. Unnamed Namespaces

Unnamed namespaces are not like other namespaces; the definition of an unnamed namespace is local to a particular file and never
spans multiple text files. An unnamed namespace may be discontiguous within a given file but does not span files. Each file has its own unnamed namespace. Names defined in an unnamed namespace are used directly; after all, there is no namespace name with which to qualify them. It is not possible to use the scope operator to refer to members of unnamed namespaces.

Names defined in an unnamed namespace are found in the same scope as the scope at which the namespace is defined. If an unnamed namespace is defined at the outermost scope in the file, then names in the unnamed namespace must differ from names defined at global scope:

int i; // global declaration for i
namespace {
    int i;
}
// error: ambiguous defined globally and in an unnested, unnamed namespace
i = 10;

The use of file static declarations is deprecated by the C++ standard. File statics should be avoided and unnamed namespaces used instead.

3. Using Namespace Members

Referring to namespace members as namespace_name::member_name is admittedly cumbersome, especially if the namespace name is long. Fortunately, there are ways to make it easier to use namespace members: using declarations、namespace aliases and using directives.

Header files should not contain using directives or using declarations except inside functions or other scopes. A header that includes a using directive or declaration at its top level scope has the effect of injecting that name into the file that includes the header. Headers should define only the names that are part of its interface, not names used in its own implementation.

A namespace alias can be used to associate a shorter synonym with a namespace name. For example

cplusplus_primer::QueryLib::Query tq;
// we could define and use an alias for cplusplus_primer::QueryLib
namespace Qlib = cplusplus_primer::QueryLib;
Qlib::Query tq;

It can be tempting to write programs with using directives, but doing so reintroduces all the problems inherent in name collisions
when using multiple libraries.

The scope of names introduced by a using directive is more complicated than those for using declarations. A using declaration puts the name directly in the same scope in which the using declaration itself appears. It is as if the using declaration is a local alias for the namespace member.

A using directive does not declare local aliases for the namespace member names. Rather, it has the effect of lifting the namespace members into the nearest scope that contains both the namespace itself and the using directive. One place where using directives are useful is in the implementation files for the namespace itself.

namespace blip {
    int bi = 16, bj = 15, bk = 23;
}
int bj = 0; // ok: bj inside blip is hidden inside a namespace
void manip()
{
    // using directive - names in blip "added" to global scope
    using namespace blip;
                    // clash between ::bj and blip::bj
                    // detected only if bj is used
    ++bi;           // sets blip::bi to 17
    ++bj;           // error: ambiguous
                    // global bj or blip::bj?
    ++::bj;         // ok: sets global bj to 1
    ++blip::bj;     // ok: sets blip::bj to 16
    int bk = 97;    // local bk hides blip::bk
    ++bk;           // sets local bk to 98
}

It is possible for names in the namespace to conflict with other names defined in the enclosing scope. For example, the blip member bj appears to manip as if it were declared at global scope. However, there is another object named bj in global scope. Such conflicts are permitted; but to use the name, we must explicitly indicate which version is wanted. Therefore, the use of bj within manip is ambiguous: The name refers both to the global variable and to the member of namespace blip.

4. Example

namespace Exercise {
    int ivar = 0;
    double dvar = 0;
    const int limit = 1000;
}
int ivar = 0;
// position 1
void manip() {
    // position 2
    double dvar = 3.1416;
    int iobj = limit + 1;
    ++ivar;
    ++::ivar;
}

What are the effects of the declarations and expressions in this code sample if using declarations for all the members of namespace Exercise are located at the location labeled position 1? At position 2 instead? Now answer the same question but replace the using declarations with a using directive for namespace Exercise.
解答:如果Exercise的所有成员使用using声明放在position 1，则 using Exercise::ivar导致重复定义的错误。manip中的dvar会屏蔽Exercise::dvar。如果Exercise的所有成员使用using声明放在position 2，manip中的dvar会出现重复定义的错误。++ivar访问到的是Exercise::ivar，++::ivar访问的是全部变量ivar。如果Exercise的所有成员使用using指示放在position 1，则 ++ivar;会导致二义性错误。如果Exercise的所有成员使用using指示放在position 2， ++ivar;依然会导致二义性错误。

5. Caution: Avoid Using Directives

using directives, which inject all the names from a namespace, are deceptively simple to use: With only a single statement, all the member names of a namespace are suddenly visible. Although this approach may seem simple, it can introduce its own problems. If an application uses many libraries, and if the names within these libraries are made visible with using directives, then we are back to square one, and the global namespace pollution problem reappears.

Moreover, it is possible that a working program will fail to compile when a new version of the library is introduced. This problem can arise if a new version introduces a name that conflicts with a name that the application is using.

Another problem is that ambiguity errors caused by using directives are detected only at the point of use. This late detection means that conflicts can arise long after introducing a particular library. If the program begins using a new part of the library, previously undetected collisions may arise.

Rather than relying on a using directive, it is better to use a using declaration for each namespace name used in the program. Doing so reduces the number of names injected into the namespace. Ambiguity errors caused by using declarations are detected at the point of declaration, not use, and so are easier to find and fix.

1. Exception Specifications

An exception specification specifies that if the function throws an exception, the exception it throws will be one of the exceptions included in the specification, or it will be a type derived from one of the listed exceptions. An exception specification follows the function parameter list. An exception specification is the keyword throw followed by a (possibly empty) list of exception types enclosed in parentheses: void recoup(int) throw(runtime_error); An empty specification list says that the function does not throw any exception:void no_problem() throw(); An exception specification is part of the function’s interface. The function definition and any declarations of the function must have the same specification. If a function declaration does not specify an exception specification, the function can throw exceptions of any type.

Unfortunately, it is not possible to know at compile time whether or which exceptions a program will throw. Violations of a function’s exception specification can be detected only at run time. If a function throws an exception not listed in its specification, the library function unexpected is invoked. By default, unexpected calls terminate , which ordinarily aborts the program.

Specifying that a function will not throw any exceptions can be helpful both to users of the function and to the compiler: Knowing that a function will not throw simplifies the task of writing exception-safe code that calls that function. We can know that we need not worry about exceptions when calling it. Moreover, if the compiler knows that no exceptions will be thrown, it can perform optimizations that are suppressed for code that might throw.

2. Exception Specifications and Member Functions

class bad_alloc : public exception {
    public:
        bad_alloc() throw();
        bad_alloc(const bad_alloc &) throw();
        bad_alloc & operator=(const bad_alloc &) throw();
        virtual ~bad_alloc() throw();
        virtual const char* what() const throw();
};

Notice that the exception specification follows the const qualifier in const member function declarations.

3. Exception Specifications and Destructors

The above isbn_mismatch class defines its destructor as

class isbn_mismatch: public std::logic_error {
    public:
        virtual ~isbn_mismatch() throw() { }
};

The isbn_mismatch class inherits from logic_error , which is one of the standard exception classes. The destructors for the standard exception classes include an empty throw() specifier; they promise that they will not throw any exceptions. When we inherit from one of these classes, then our destructor must also promise not to throw any exceptions.

Our out_of_stock class had no members, and so its synthesized destructor does nothing that might throw an exception. Hence, the compiler can know that the synthesized destructor will abide by the promise not to throw.

The isbn_mismatch class has two members of class string, which means that the synthesized destructor for isbn_mismatch calls the string destructor. The C++ standard stipulates that string destructor, like any other library class destructor, will not throw an exception. However, the library destructors do not define exception specifications. In this case, we know, but the compiler doesn’t, that the string destructor won’t throw. We must define our own destructor to reinstate the promise that the destructor will not throw.

4. Exception Specifications and Virtual Functions

A virtual function in a base class may have an exception specification that differs from the exception specification of the corresponding virtual in a derived class. However, the exception specification of a derived-class virtual function must be either equally or more restrictive than the exception specification of the corresponding base-class virtual function.

class Base {
    public:
        virtual double f1(double) throw ();
        virtual int f2(int) throw (std::logic_error);
        virtual std::string f3() throw (std::logic_error, std::runtime_error);
};
class Derived : public Base {
    public:
        // error: exception specification is less restrictive than Base::f1's
        double f1(double) throw (std::underflow_error);
        // ok: same exception specification as Base::f2
        int f2(int) throw (std::logic_error);
        // ok: Derived f3 is more restrictive
        std::string f3() throw ();
}

By restricting which exceptions the derived classes will throw to those listed by the base class, we can write our code knowing what exceptions we must handle.

5. Function Pointer Exception Specifications

An exception specification is part of a function type. As such, exception specifications can be provided in the definition of a pointer to function:void (*pf)(int) throw(runtime_error); When a pointer to function with an exception specification is initialized from (or assigned to) another pointer (or to the address of a function), the exception specifications of both pointers do not have to be identical. However, the specification of the source pointer must be at least as restrictive as the specification of the destination pointer.

void recoup(int) throw(runtime_error);
// ok: recoup is as restrictive as pf1
void (*pf1)(int) throw(runtime_error) = recoup;
// ok: recoup is more restrictive than pf2
void (*pf2)(int) throw(runtime_error, logic_error) = recoup;
// error: recoup is less restrictive than pf3
void (*pf3)(int) throw() = recoup;
// ok: recoup is more restrictive than pf4
void (*pf4)(int) = recoup;

1. Standard exception Class Hierarchy

2. User-Defined Exception Types

class out_of_stock: public std::runtime_error {
    public:
    explicit out_of_stock(const std::string &s):std::runtime_error(s) 
    { }
};
class isbn_mismatch: public std::logic_error {
    public:
        explicit isbn_mismatch(const std::string &s): std::logic_error(s) 
        { }
        isbn_mismatch(const std::string &s, const std::string &lhs, const std::string &rhs):
                                        std::logic_error(s), left(lhs), right(rhs) { }
        const std::string left, right;
        virtual ~isbn_mismatch() throw() { }
};

3. Automatic Resource Deallocation

We know that local objects are automatically destroyed when an exception occurs. The fact that destructors are run has important implication for the design of applications.

void f()
{
    vector<string> v; // local vector
    string s;
    while (cin >> s)
        v.push_back(s); // populate the vector
        string *p = new string[v.size()]; // dynamic array
        // remaining processing
        // it is possible that an exception occurs in this code
        // function cleanup is bypassed if an exception occurs
        delete [] p;
    } // v destroyed automatically when the function exits

If an exception occurs inside the function, then the vector will be destroyed but the array will not be freed. The problem is that the array is not freed automatically. No matter when an exception occurs, we are guaranteed that the vector destructor is run.

4. Using Classes to Manage Resource Allocation

The fact that destructors are run leads to an important programming technique that makes programs more exception safe . By exception safe, we mean that the programs operate correctly even if an exception occurs. In this case, the “safety” comes from ensuring that any resouce that is allocated is properly freed if an exception occurs. We can guarantee that resources are properly freed by defining a class to encapsulate the acquisition and release of a resource.

5. The auto_ptr Class

The standard-library auto_ptr class is an example of the exception-safe “resource allocation is initialization” technique. The aut_ptr class is a template that takes a single type parameter. It provides exception safety for dynamically allocated
objects. The auto_ptr class is defined in the memory header. auto_ptr can be used only to manage single objects returned from
new. It does not manage dynamically allocated arrays. As we’ll see, auto_ptr has unusual behavior when copied or assigned. As a result, auto_ptrs may not be stored in the library container types.

void f()
{
    int *ip = new int(42); // dynamically allocate a new object
    // code that throws an exception that is not caught inside f
    delete ip; // return the memory before exiting
}
void f()
{
auto_ptr<int> ap(new int(42)); // allocate a new object
// code that throws an exception that is not caught inside f
}
// auto_ptr freed automatically when function ends

To determine whether the auto_ptr object refers to an object, we can compare the return from get with 0. get should be used only to interrogate an auto_ptr or to use the returned pointer value. get should not be used as an argument to create another auto_ptr. Using get member to initialize another auto_ptr violates the class design principle that only one auto_ptr holds a given pointer at any one time. If two auto_ptrs hold the same pointer, then the pointer will be deleted twice.

6. Copy and Assignment on auto_ptr Are Destructive Operations

When we copy an auto_ptr or assign its value to another auto_ptr, ownership of the underlying object is transferred from the original to the copy. The original auto_ptr is reset to an unbound state. Unlike other copy or assignment operations, auto_ptr copy and assignment change the right-hand operand. As a result, both the left- and right-hand operands to assignment must be
modifiable lvalues. Because copy and assignment are destructive operations, auto_ptrs cannot be stored in the standard containers. The library container classes require that two objects be equal after a copy or assignment. This requirement is not met by auto_ptr. If we assign ap2 to ap1, then after the assignment ap1 != ap2.

7. Caution: Auto_ptr Pitfalls

The auto_ptr class template provides a measure of safety and convenience for handling dynamically allocated memory. To use auto_ptr correctly, we must adhere to the restrictions that the class imposes:

• Do not use an auto_ptr to hold a pointer to a statically allocated object. Otherwise, when the auto_ptr itself is destroyed, it will attempt to delete a pointer to a nondynamically allocated object, resulting in undefined behavior.
• Never use two auto_ptrs to refer to the same object. One obvious way to make this mistake is to use the same pointer to initialize or to reset two different auto_ptr objects. A more subtle way to make this mistake would be to use the result from get on one auto_ptr to initialize or reset another.
• Do not use an auto_ptr to hold a pointer to a dynamically allocated array. When the auto_ptr is destroyed, it frees only a single objectit uses the plain delete operator, not the array delete [] operator.
• Do not store an auto_ptr in a container. Containers require that the types they hold define copy and assignment to behave similarly to how those operations behave on the built-in types: After the copy (or assignment), the two objects must have the same value. auto_ptr does not meet this requirement.

1. Exception Handling

Exception handling relies on the problem-detecting part throwing an object to a handler. The type and contents of that object allow the two parts to communicate about what went wrong.

Sales_item operator+(const Sales_item& lhs, const Sales_item& rhs)
{
    if (!lhs.same_isbn(rhs))
        throw runtime_error("Data must refer to same ISBN");
   
    Sales_item ret(lhs);
    return
    ret += rhs;
    return ret;
}

Sales_item item1, item2, sum;
while (cin >> item1 >> item2) {
    try {
        sum = item1 + item2;
    } catch (const runtime_error &e) {
        cerr << e.what() << " Try again.\n"
             << endl;
    }
}

2. Throwing an Exception of Class Type

An exception is raised by throwing an object. The type of that object determines which handler will be invoked. The selected handler is the one nearest in the call chain that matches the type of the object.

Exceptions are thrown and caught in ways that are similar to how arguments are passed to functions. An exception can be an object of any type that can be passed to a nonreference parameter, meaning that it must be possible to copy objects of that type. Recall that when we pass an argument of array or function type, that argument is automatically converted to an pointer. The same automatic conversion happens for objects that are thrown. As a consequence, there are no exceptions of array or function types. Instead, if we throw an array, the thrown object is converted to a pointer to the first element in the array. Similarly, if we throw a function, the function is converted to a pointer to the function. The fact that control passes from one location to another has two important implications:

• Functions along the call chain are prematurely exited. Following section discusses what happens when functions are exited due to an exception.
• In general, the storage that is local to a block that throws an exception is not around when the exception is handled.

Because local storage is freed while handling an exception, the object that is thrown is not stored locally. Instead, the throw expression is used to initialize a special object referred to as the exception object . The exception object is managed by the compiler and is guaranteed to reside in space that will be accessible to whatever catch is invoked. This object is created by a
throw , and is initialized as a copy of the expression that is thrown. The exception object is passed to the corresponding catch and is destroyed after the exception is completely handled. The exception object is created by copying the result of the thrown
expression; that result must be of a type that can be copied. What’s important to know is how the form of the throw expression interacts with types related by inheritance. When an exception is thrown, the static, compile-time type of the thrown object determines the type of the exception object.

The one case where it matters that a throw expression throws the static type is if we dereference a pointer in a throw. The result of dereferencing a pointer is an object whose type matches the type of the pointer. If the pointer points to a type from an inheritance hierarchy, it is possible that the type of the object to which the pointer points is different from the type of
the pointer. Regardless of the object’s actual type, the type of the exception object matches the static type of the pointer. If that pointer is a base-class type pointer that points to a derived-type object, then that object is sliced down; only the base-class part is thrown.

In particular, it is always an error to throw a pointer to a local object for the same reasons as it is an error to return a pointer to a local object from a function. It is usually a bad idea to tHRow a pointer: Throwing a pointer requires that the object to which the pointer points exist wherever the corresponding handler resides.

3. Stack Unwinding

When an exception is thrown, execution of the current function is suspended and the search begins for a matching catch clause. The search starts by checking whether the tHRow itself is located inside a try block. If so, the catch clauses associated with that try are examined to see if one of them matches the thrown object. If a matching catch is found, the exception is
handled. If no catch is found, the current function is exitedits memory is freed and local objects are destroyed and the search continues in the calling function.

If the call to the function that threw is in a try block, then the catch clauses associated with that try are examined. If a matching catch is found, the exception is handled. If no matching catch is found, the calling function is also exited, and the search continues in the function that called this one.

This process, known as stack unwinding, continues up the chain of nested function calls until a catch clause for the exception is found. As soon as a catch clause that can handle the exception is found, that catch is entered, and execution continues within this handler. When the catch completes, execution continues at the point immediately after the last catch clause associated with that try block.

When a function is exited due to an exception, the compiler guarantees that the local objects are properly destroyed. During stack unwinding, the memory used by local objects is freed and destructors for local objects of class type are run.

Destructors are often executed during stack unwinding. When destructors are executing, the exception has been raised but not yet handled. While stack unwinding is in progress for an exception, a destructor that throws another exception of its own that it does not also handle, causes the library terminate function is called. Ordinarily, terminate calls abort , forcing an abnormal exit from the entire program. Because terminate ends the program, it is usually a very bad idea for a destructor to do anything that might cause an exception. The standard library types all guarantee that their destructors will not raise an exception.

Unlike destructors, it is often the case that something done inside a constructor might throw an exception. If an exception occurs while constructing an object, then the object might be only partially constructed. Some of its members might have been initialized, and others might not have been initialized before the exception occurs. Even if the object is only partially constructed, we are guaranteed that the constructed members will be properly destroyed. Similarly, an exception might occur when initializing the elements of an array or other container type. Again, we are guaranteed that the constructed elements will be destroyed.

uncaught exceptions terminate the program.

3. Catching an Exception

The exception specifier in a catch clause looks like a parameter list that contains exactly one parameter. The exception specifier is a type name followed by an optional parameter name. During the search for a matching catch , the catch that is found is not necessarily the one that matches the exception best. Instead, the catch that is selected is the first catch found that can
handle the exception. As a consequence, in a list of catch clauses, the most specialized catch must appear first. Most conversions are not allowed the types of the exception and the catch specifier must match exactly with only a few possible differences:

• Conversions from non const to const are allowed. That is, a throw of a non const object can match a catch specified to take a const reference.
• Conversions from derived type to base type are allowed.
• An array is converted to a pointer to the type of the array; a function is converted to the appropriate pointer to function type.

In particular, neither the standard arithmetic conversions nor conversions defined for class types are permitted.

When a catch is entered, the catch parameter is initialized from the exception object. As with a function parameter, the exception-specifier type might be a reference. The exception object itself is a copy of the object that was thrown. Whether the exception object is copied again into the catch site depends on the exception-specifier type. Like a parameter declaration, an exception specifier for a base class can be used to catch an exception object of a derived type. Usually, a catch clause that handles an exception of a type related by inheritance ought to define its parameter as a reference. Because objects (as opposed to references) are not polymorphic.

Because catch clauses are matched in the order in which they appear, programs that use exceptions from an inheritance hierarchy must order their catch clauses so that handlers for a derived type occurs before a catch for its base type.

4. Rethrow

A catch can pass the exception out to another catch further up the list of function calls by rethrowing the exception. A rethrow is a throw that is not followed by a type or an expression: throw; An empty throw can appear only in a catch or in a function called (directly or indirectly) from a catch. If an empty throw is encountered when a handler is not active, terminate is called.

The exception that is thrown is the original exception object, not the catch parameter. When a catch parameter is a base type, then we cannot know the actual type thrown by a rethrow expression. That type depends on the dynamic type of the exception object, not the static type of the catch parameter. In general, a catch might change its parameter. If, after changing its parameter, the catch rethrows the exception, then those changes will be propagated only if the exception specifier is a reference:

catch (my_error &eObj) { // specifier is a reference type
    eObj.status = severeErr; // modifies the exception object
    throw; // the status member of the exception object is severeErr
} catch (other_error eObj) { // specifier is a nonreference type
    eObj.status = badErr; // modifies local copy only
    throw; // the status member of the exception rethrown is unchanged
}

5. The Catch-All Handler

A catch(…) is often used in combination with a rethrow expression. The catch does whatever local work can be done and then rethrows the exception:

void manip() {
    try {
        // actions that cause an exception to be thrown
    }
    catch (...) {
        // work to partially handle the exception
        throw;
    }
}

6. Function Try Blocks and Constructors

Constructor initializers are processed before the constructor body is entered. A catch clause inside the constructor body cannot handle an exception that might occur while processing a constructor initializer. To handle an exception from a constructor initializer, we must write the constructor as a function try block.

template <class T> Handle<T>::Handle(T *p)
try : ptr(p), use(new size_t(1))
{
    // empty function body
} 
catch(const std::bad_alloc &e)
{ 
    handle_out_of_memory(e);
}

1. Pointers to Functions

A function’s type is determined by its return type and its parameter list. A function’s name is not part of its type:

// pf points to function returning bool that takes two const string references
bool (*pf)(const string &, const string &);

// The parentheses around  *pf are necessary
// declares a function named pf that returns a bool*
bool *pf(const string &, const string &);

typedef bool (*cmpFcn)(const string &, const string &);

2. Initializing and Assigning Pointers to Functions

When we use a function name without calling it, the name is automatically treated as a pointer to a function.

cmpFcn pf1 = lengthCompare;  \\  automatically converted to a function pointer
cmpFcn pf2 = &lengthCompare;

string::size_type sumLength(const string&, const string&);
bool cstringCompare(char*, char*);
// pointer to function returning bool taking two const string&
cmpFcn pf;
pf = sumLength; // error: return type differs

A pointer to a function can be used to call the function to which it refers. We can use the pointer directly there is no need to use the dereference operator to call the function

cmpFcn pf = lengthCompare;
lengthCompare("hi", "bye"); // direct call
pf("hi", "bye"); // equivalent call: pf1 implicitly dereferenced
(*pf)("hi", "bye"); // equivalent call: pf1 explicitly dereferenced

3. Function Pointer Parameters

// third parameter is a function type and is automatically treated as a pointer to function
void useBigger(const string &, const string &,
                        bool(const string &, const string &));

// equivalent declaration: explicitly define the parameter as a pointer to function
void useBigger(const string &, const string &,
                        bool (*)(const string &, const string &));

4. Returning a Pointer to Function

int (*ff(int))(int*, int), The best way to read function pointer declarations is from the inside out, starting with the name being declared. Typedefs can make such declarations considerably easier to read:

// PF is a pointer to a function returning an int, taking an int* and an int
typedef int (*PF)(int*, int);
PF ff(int); // ff returns a pointer to function

We can define a parameter as a function type. A function return type must be a pointer to function; it cannot be a function. An argument to a parameter that has a function type is automatically converted to the corresponding pointer to function type. The same conversion does not happen when returning a function:

// func is a function type, not a pointer to function!
typedef int func(int*, int);
void f1(func); // ok: f1 has a parameter of function type
func f2(int); // error: f2 has a return type of function type
func *f3(int); // ok: f3 returns a pointer to function type

1. *** Overloading and Function Templates ***

A function template can be overloaded: We can define multiple function templates with the same name but differing numbers or types of parameters. We also can define ordinary nontemplate functions with the same name as a function template. However, overloaded function templates may lead to ambiguities. The steps used to resolve a call to an overloaded function in which there are both ordinary functions and function templates are as follows:

• Build the set of candidate functions for this function name, including:
  a. Any ordinary function with the same name as the called function.
  b. Any function-template instantiation for which template argument deduction finds template arguments that match the function arguments used in the call.
• Determine which, if any, of the ordinary functions are viable. Each template instance in the candidate set is viable, because template argument deduction ensures that the function could be called.
• Rank the viable functions by the kinds of conversions, if any, required to make the call, remembering that the conversions allowed to call an instance of a template function are limited.
  a. If only one function is selected, call this function.
  b. If the call is ambiguous, remove any function template instances from the set of viable functions.
• Rerank the viable functions excluding the function template instantiations.
  a. If only one function is selected, call this function.
  b. Otherwise, the call is ambiguous.

2. An Example of Function-Template Matching

template <typename T> int compare(const T&, const T&);
template <class U, class V> int compare(U, U, V);
int compare(const char*, const char*);

// calls compare(const T&, const T&) with T bound to int
compare(1, 0);

// calls compare(U, U, V), with U and V bound to vector<int>::iterator
vector<int> ivec1(10), ivec2(20);
compare(ivec1.begin(), ivec1.end(), ivec2.begin());
int ia1[] = {0,1,2,3,4,5,6,7,8,9};

// calls compare(U, U, V) with U bound to int* and V bound to vector<int>::iterator
compare(ia1, ia1 + 10, ivec1.begin());

// calls the ordinary function taking const char* parameters
const char const_arr1[] = "world", const_arr2[] = "hi";
compare(const_arr1, const_arr2);

// calls the ordinary function taking const char* parameters
char ch_arr1[] = "world", ch_arr2[] = "hi";
compare(ch_arr1, ch_arr2);

再进行分析前，先看一个小例子：

int compare(const char (&v1)[3], const char (&v2)[3]);
int compare(const char *v1, const char *v2);
int main(int argc, char **argv)
{
    const char array1[] = "wo";
    const char array2[] = "hi";

    compare(array1, array2);
}

error: call of overloaded ‘compare(const char [3], const char [3])’ is ambiguous
note: candidates are: int compare(const char (&)[3], const char (&)[3])
note:                 int compare(const char*, const char*)
// 即编译器认为这个两个函数是同样好的。

compare(const_arr1, const_arr2)：它的candidates只有int compare(const char*, const char*). 因为模板函数int compare(const T&, const T&)中的参数类型是引用，const_arr1的类型是const char[6]，const_arr2的类型是const char[3]，两个实参的类型不同，所以不能使用模板进行实例化。
compare(const_arr1, const_arr1)：它的candidates有int compare(const char*, const char*)和int compare(const char (&)[6], const char (&)[6]，由前面的例子可知，它们两个是一样好的，但是依据匹配规则，如果出现ambiguous的情况，则剔除由函数模板实例化而来的函数。
compare(ch_arr1, ch_arr2): 与compare(const_arr1, const_arr2)类似。

3. Conversions and Overloaded Function Templates

Let’s look at two examples of why it is hard to design overloaded functions that work properly when there are both template and nontemplate versions in the overload set. First, consider a call to compare using pointers instead of the arrays themselves:

char *p1 = ch_arr1, *p2 = ch_arr2;
compare(p1, p2);

This call matches the template version! Ordinarily, we expect to get the same function whether we pass an array or a pointer to an element to that array. In this case, however, the function template is an exact match for the call, binding char to T. The plain version still requires a conversion from char to const char* , so the function template is preferred. 此处没有理解啊？？？

Another change that has surprising results is what happens if the template version of compare has a parameter of type T instead of a const reference to T:

template <typename T> int compare2(T, T);

// calls compare(T, T) with T bound to char*
compare(ch_arr1, ch_arr2);
// calls compare(T, T) with T bound to char*
compare(p1, p2);
// calls the ordinary function taking const char*
parameters compare(const_arr1, const_arr2);
const char *cp1 = const_arr1, *cp2 = const_arr2;
// calls the ordinary function taking const char* parameters
compare(cp1, cp2);

In these cases, the plain function and the function template are exact matches. As always, when the match is equally good, the nontemplate version is preferred.

It is hard to design overloaded function sets involving both function templates and nontemplate functions. Because of the likelihood of surprise to users of the functions, it is almost always better to define a function-template specialization than to use a nontemplate version.

1. Specializing a Class Template

Our Queue class has a problem similar to the one in compare when used with C-style strings. In this case, the problem is in the push function. That function copies the value it’s given to create a new element in the Queue. By default, copying a C-style character string copies only the pointer, not the characters.

template<> class Queue<const char*> {
    public:
        // no copy control: Synthesized versions work for this class
        // similarly, no need for explicit default constructor either
        void push(const char*);
        void pop() {real_queue.pop();}
        bool empty() const {return real_queue.empty();}
        // Note: return type does not match template parameter type
        std::string front() {return real_queue.front();}
        const std::string &front() const
        {return real_queue.front();}
    private:
        Queue<std::string> real_queue; // forward calls to real_queue
};

It is worth noting that a specialization may define completely different members than the template itself. If a specialization fails to define a member from the template, that member may not be used on objects of the specilization type. The member definitions of the class template are not used to create the definitions for the members of an explicit specialization.

A class template specialization ought to define the same interface as the template it specializes. Doing otherwise will surprise users when they attempt to use a member that is not defined.

2. Class Specialization Definition

When a member is defined outside the class specialization, it is not preceded by the tokens template<>.

void Queue<const char*>::push(const char* val)
{
    return real_queue.push(val);
}

3. Specializing Members but Not the Class

If we look a bit more deeply at our class, we can see that we can simplify our code: Rather than specializing the whole template, we can specialize just the push and pop members. We’ll specialize push to copy the character array and pop to free the memory we used for that copy:

template <>
void Queue<const char*>::push(const char *const &val)
{
    // allocate a new character array and copy characters from val
    char* new_item = new char[strlen(val) + 1];
    strncpy(new_item, val, strlen(val) + 1);
    // store pointer to newly allocated and initialized element
    QueueItem<const char*> *pt = new QueueItem<const char*>(new_item);
    // put item onto existing queue
    if (empty())
        head = tail = pt; // queue has only one element
    else {
        tail->next = pt; // add new element to end of queue
        tail = pt;
    }
}

template <>
void Queue<const char*>::pop()
{
    // remember head so we can delete it
    QueueItem<const char*> *p = head;
    delete head->item; // delete the array allocated in push
    head = head->next; // head now points to next element
    delete p; // delete old head element
}

4. Specialization Declarations

Member specializations are declared just as any other function template specialization. They must start with an empty template parameter list:

// push and pop specialized for const char*
template <>
void Queue<const char*>::push(const char* const &);
template <> void Queue<const char*>::pop();

5. *** Class-Template Partial Specializations ***

If a class template has more than one template parameter, we might want to specialize some but not all of the template parameters. We can do so using a class template partial specialization:

template <class T1, class T2>
class some_template
{
    public:
        void print()
        {
            cout << "hello" << endl;
        }
};

// partial specialization: fixes T2 as int and allows T1 to vary
template <class T1>
class some_template<T1, int>
{
};

As with any other class template, a partial specialization is instantiated implicitly when used in a program:

some_template<int, string> foo; // uses template
some_template<string, int> bar; // uses partial specialization

The definition of a partial specialization is completely disjointed from the definition of the generic template. The partial specialization may have a completely different set of members from the generic class template. The generic definitions for the members of a class template are never used to instantiate the members of the class template partial specialization.

Demo<double, int> d;
d.print();

// error: ‘class Demo<double, int>’ has no member named ‘print’

1. Defining the Generic Handle Class

To create a Handle , a user will be expected to pass the address of a dynamically allocated object of the type (or a type
derived from that type) managed by the Handle . From that point on, the Handle will “own” the given object. In particular, the Handle class will assume responsibility for deleting that object once there are no longer any Handle s attached to it. Once an object is bound to a Handle, the user must not delete that object.

template <class T> class Handle {
    public:
        // unbound handle
        Handle(T *p = 0): ptr(p), use(new size_t(1)) { }
        // overloaded operators to support pointer behavior
        T& operator*();
        T* operator->();
        const T& operator*() const;
        const T* operator->() const;
        // copy control: normal pointer behavior, but last Handle deletes the object
        Handle(const Handle& h): ptr(h.ptr), use(h.use)
        { ++*use; }
        Handle& operator=(const Handle&);
        ~Handle() { rem_ref(); }
    private:
        T* ptr; // shared object
        size_t *use; // count of how many Handle spointto *ptr
        void rem_ref()
        { if (--*use == 0) { delete ptr; delete use; } }
};

template <class T>
inline Handle<T>& Handle<T>::operator=(const Handle &rhs)
{
    ++*rhs.use; // protect against self-assignment
    rem_ref(); // decrement use count and delete pointers if needed
    ptr = rhs.ptr;
    use = rhs.use;
    return *this;
}

2. Using the Handle

We intend this class to be used by other classes in their internal implementations. However, as an aid to understanding how the Handle class works, we’ll look at a simpler example first. This example illustrates the behavior of the Handle by allocating an int and binding a Handle to that newly allocated object:

{ // new scope
    // user allocates but must not delete the object to which the Handle is attached
    Handle<int> hp(new int(42));
    { // new scope
        Handle<int> hp2 = hp; // copies pointer; use count incremented
        cout << *hp << " " << *hp2 << endl; // prints 42 42
        *hp2 = 10; // changes value of shared underlying int
    } // hp2 goes out of scope; use count is decremented
    cout << *hp << endl; // prints 10
} // hp goes out of scope; its destructor deletes the int

As an example of using Handle in a class implementation, we might reimplement our Sales_item class. This version of the class defines the same interface, but we can eliminate the copy-control members by replacing the pointer to Item_base by a Handle:

class Sales_item {
    public:
        // default constructor: unbound handle
        Sales_item(): h() { }
        // copy item and attach handle to the copy
        Sales_item(const Item_base &item): h(item.clone()) { }
        // no copy control members: synthesized versions work
        // member access operators: forward their work to the Handle class
        const Item_base& operator*() const { return *h; }
        const Item_base* operator->() const
        { return h.operator->(); }
    private:
        Handle<Item_base> h; // use-counted handle
};

3. *** Template Specializations ***

It is not always possible to write a single template that is best suited for every possible template argument with which the template might be instantiated. In some cases, the general template definition is simply wrong for a type. The general definition might not compile or might do the wrong thing. At other times, we may be able to take advantage of some specific knowledge
about a type to write a more efficient function than the one that is instantiated from the template. Let’s look again at our compare function template. If we call this template definition on two const char* arguments, the function compares the pointer values.

template <typename T>
int compare(const T &v1, const T &v2)
{
    if (v1 < v2) return -1;
    if (v2 < v1) return 1;
    return 0;
}

4. Specializing a Function Template

A template spacialization is a separate definition in which the actual type(s) or value(s) of one or more template parameter(s) is (are) specified. The declaration for the specialization must match that of the corresponding template.

// special version of compare to handle C-style character strings
template <>
int compare<const char*>(const char* const &v1,
const char* const &v2)
{
    return strcmp(v1, v2);
}

Now when we call compare , passing it two character pointers, the compiler will call our specialized version. It will call the generic version for any other argument types (including plain char*,也就是说要完全匹配):

const char *cp1 = "world", *cp2 = "hi";
int i1, i2;
compare(cp1, cp2); // calls the specialization
compare(i1, i2); // calls the generic version instantiated with int

As with any function, we can declare a function template specialization without defining it. A template specialization declaration looks like the definition but omits the function body. If the template arguments can be inferred from the function parameter
list, there is no need to explicitly specify the template arguments:

// error: invalid specialization declarations
// missing template<>
int compare<const char*>(const char* const&, const char* const&);

// error: function parameter list missing
template<> int compare<const char*>;

// ok: explicit template argument const char* deduced from parameter types
template<> int compare(const char* const&, const char* const&);

5. Function Overloading versus Template Specializations

Omitting the empty template parameter list, template<> , on a specialization may have surprising effects. If the specialization syntax is missing, then the effect is to declare an overloaded nontemplate version of the function:

// generic template definition
template <class T>
int compare(const T& t1, const T& t2) { /* ... */ }
// OK: ordinary function declaration
int compare(const char* const&, const char* const&);

The definition of compare does not define a template specialization. Instead, it declares an ordinary function with a return type and a parameter list that could match those of a template instantiation.

We’ll look at the interaction of overloading and templates in more detail in the next section. For now, what’s important to know is that when we define a nontemplate function, normal conversions are applied to the arguments. When we specialize a template, conversions are not applied to the argument types. In a call to a specialized version of a template, the argument type(s) in the call must match the specialized version function parameter type(s) exactly. If they don’t, then the compiler will instantiate an instantiation for the argument(s) from the template definition.

If a program consists of more than one file, the declaration for a template specialization must be visible in every file in which the specialization is used. As with other function declarations, declarations for template specializations should be included in a header file. That header should then be included in every source file that uses the specialization.

6. Ordinary Scope Rules Apply to Specializations

Before we can declare or define a specialization, a declaration for the template that it specializes must be in scope. Similarly, a declaration for the specialization must be in scope before that version of the template is called:

// define the general compare template
template <class T>
int compare(const T& t1, const T& t2) { /* ... */ }

int main() {
// uses the generic template definition
int i = compare("hello", "world");
// ...
}

// invalid program: explicit specialization after call
template<>
int compare<const char*>(const char* const& s1, const char* const& s2)
{ /* ... */ }

1. Member Templates

Any class (template or otherwise) may have a member that is itself a class or function template. Such members are referred to as member templates. One example of a member template is the assign member of the standard containers. The version assign that takes two iterators uses a template parameter to represent the type of its iterator parameters. Another member template example is the container constructor that takes two iterators. This constructor and the assign member allow containers to be built from sequences of different but compatible element types and/or different container types.

Consider the Queue copy constructor: It takes a single parameter that is a reference to a Queue . If we wanted to create a Queue by copying elements from a vector, we could not do so; there is no conversion from vector to Queue . Similarly, if we wanted to copy elements from a Queue into a Queue, we could not do so. Again, even though we can convert a short
to an int , there is no conversion from Queue to Queue. The same logic applies to the Queue assignment operator, which also takes a parameter of type Queue&.

The problem is that the copy constructor and assignment operator fix both the container and element type. We’d like to define a constructor and an assign member that allow both the container and element type to vary. When we need a parameter type to vary, we need to define a function template. In this case, we’ll define the constructor and assign member to take a pair ofiterators that denote a range in some other sequence. These functions will have a single template type parameter that represents an iterator type.

2. Defining a Member Template

template <class Type> class Queue {
    public:
        // construct a Queue from a pair of iterators on some sequence
        template <class It>
        Queue(It beg, It end):
        head(0), tail(0) { copy_elems(beg, end); }
        // replace current Queue by contents delimited by a pair of iterators
        template <class Iter> void assign(Iter, Iter);
        // rest of Queue class as before
    private:
        // version of copy to be used by assign to copy elements from iterator range
        template <class Iter> void copy_elems(Iter, Iter);
}

When we define a member template outside the scope of a class template, we must include both template parameter lists:

template <class T> template <class Iter>
void Queue<T>::assign(Iter beg, Iter end)
{
    destroy(); // remove existing elements in this Queue
    copy_elems(beg, end); // copy elements from the input range
}

When a member template is a member of a class template, then its definition must include the class-template parameters as well as its own template parameters. The class-template parameter list comes first, followed by the member’s own template parameter list. The definition of assign starts with template <class T> template <class Iter>.

3. Member Templates and Instantiation

Like any other member, a member template is instantiated only when it is used in a program. Member templates have two kinds of
template parameters: Those that are defined by the class and those defined by the member template itself. The class template parameters are fixed by the type of the object through which the function is called. The template parameters defined by the member act like parameters of ordinary function templates. These parameters are resolved through normal template argument deduction.

short a[4] = { 0, 3, 6, 9 };
// instantiates Queue<int>::Queue(short *, short *)
Queue<int> qi(a, a + 4); // copies elements from a into qi
vector<int> vi(a, a + 4);
// instantiates Queue<int>::assign(vector<int>::iterator,
//                                          vector<int>::iterator)
qi.assign(vi.begin(), vi.end());

4. The Complete Queue Class

// declaration that Queue is a template needed for friend declaration in QueueItem
template <class Type> class Queue;
// function template declaration must precede friend declaration in QueueItem
template <class T>
    std::ostream& operator<<(std::ostream&, const Queue<T>&);

template <class Type> class QueueItem {
    friend class Queue<Type>;
    // needs access to item and next
    friend std::ostream& // defined on page 659
    operator<< <Type> (std::ostream&, const Queue<Type>&);
    // private class: no public section
    QueueItem(const Type &t): item(t), next(0) { }
    Type item; // value stored in this element
    QueueItem *next; // pointer to next element in the Queue
};

template <class Type> class Queue {
    // needs access to head
    friend std::ostream& // defined on page 659
                operator<< <Type> (std::ostream&, const Queue<Type>&);
    public:
        // empty Queue
        Queue(): head(0), tail(0) { }
        // construct a Queue from a pair of iterators on some sequence
        template <class It>
        Queue(It beg, It end):
                head(0), tail(0) { copy_elems(beg, end); }
        // copy control to manage pointers to QueueItems in the Queue
        Queue(const Queue &Q): head(0), tail(0)
        { copy_elems(Q); }
        Queue& operator=(const Queue&); // left as exercise for the reader
        ~Queue() { destroy(); }
        // replace current Queue by contents delimited by a pair of iterators
        template <class Iter> void assign(Iter, Iter);
        // return element from head of Queue
        // unchecked operation: front on an empty Queue is undefined
        Type& front() { return head->item; }
        const Type &front() const { return head->item; }
        void push(const Type &);// defined on page 652
        void pop(); // defined on page 651
        bool empty() const { // true if no elements in the Queue
        return head == 0;
        }
    private:
        QueueItem<Type> *head; // pointer to first element in Queue
        QueueItem<Type> *tail; // pointer to last element in Queue
        // utility functions used by copy constructor, assignment, and destructor
        void destroy(); // defined on page 651
        void copy_elems(const Queue&); // defined on page 652
        // version of copy to be used by assign to copy elements from iterator range
        // defined on page 662
        template <class Iter> void copy_elems(Iter, Iter);
};

// Inclusion Compilation Model: include member function definitions as well
#include "Queue.cc"

5. static Members of Class Templates

template <class T> class Foo {
    public:
        static std::size_t count() { return ctr; }
        // other interface members
    private:
        static std::size_t ctr;
        // other implementation members
};

// Each object shares the same Foo<int>::ctrand Foo<int>::count members
Foo<int> fi, fi2, fi3;

// has static members Foo<string>::ctrand Foo<string>::count
Foo<string> fs;

Foo<int> fi, fi2; // instantiates Foo<int> class
size_t ct = Foo<int>::count(); // instantiates Foo<int>::count
ct = fi.count(); // ok: uses Foo<int>::count
ct = fi2.count(); // ok: uses Foo<int>::count
ct = Foo::count(); // error: which template instantiation?

As with any other static data member, there must be a definition for the data member that appears outside the class. In the case of a class template static , the member definition must inidicate that it is for a class template:

template <class T>
size_t Foo<T>::ctr = 0; // define and initialize ctr

1. Class-Template Member Functions

The definition of a member function of a class template has the following form:

• It must start with the keyword template followed by the template parameter list for the class.
• It must indicate the class of which it is a member.
• The class name must include its template parameters.

template <class T> ret-type Queue<T>::member-name

template <class Type>
void Queue<Type>::copy_elems(const Queue &orig)
{
    for (QueueItem<Type> *pt = orig.head; pt; pt = pt->next)
        push(pt->item);
}

Member functions of class templates are themselves function templates. Like any other function template, a member function of a class template is used to generate instantiations of that member. Unlike other function templates, the compiler does not perform template-argument deduction when instantiating class template member functions. Instead, the template parameters of a class template member function are determined by the type of the object on which the call is made. For example, when we call the push member of an object of type Queue , the push function that is instantiated is void Queue<int>::push(const int &val).

Queue<int> qi; // instantiates class Queue<int>
short s = 42;
int i = 42;
// ok: s converted to int and passed to push
qi.push(s); // instantiates Queue<int>::push(const int&)
qi.push(i); // uses Queue<int>::push(const int&)
f(s); // instantiates f(const short&)
f(i); // instantiates f(const int&)

Member functions of a class template are instantiated only for functions that are used by the program. If a function is never used, then that member function is never instantiated. This behavior implies that types used to instantiate a template need to meet only the requirements of the operations that are actually used. When we define an object of a template type, that definition causes the class template to be instantiated. Defining an object also instantiates whichever constructor was used to initialize the object, along with any members called by that constructor:

// instantiates Queue<string> class and Queue<string>::Queue()
Queue<string> qs;
qs.push("hello"); // instantiates Queue<string>::push

template <class Type> void Queue<Type>::push(const Type &val)
{
    // allocate a new QueueItem object
    QueueItem<Type> *pt = new QueueItem<Type>(val);
    // put item onto existing queue
    if (empty())
        head = tail = pt; // the queue now has only one element
    else {
        tail->next = pt; // add new element to end of the queue
        tail = pt;
    }
}

in turn instantiates the companion QueueItem class and its constructor. The QueueItem members in Queue are pointers. Defining a pointer to a class template doesn’t instantiate the class; the class is instantiated only when we use such a pointer. Thus, QueueItem is not instantiated when we create a Queue object. Instead, the QueueItem class is instanatiated when a Queue member such as front, push, or pop is used.

2. Template Arguments for Nontype Parameters

template <int hi, int wid>
class Screen {
    public:
        // template nontype parameters used to initialize data members
        Screen(): screen(hi * wid, '#'), cursor (0),
                                height(hi), width(wid) { }
    // ...
    private:
        std::string screen;
        std::string::size_type cursor;
        std::string::size_type height, width;
};

// define Screen() outside the class
template<int hi, int wid>
Screen<hi, wid>::Screen<hi, wid>() : screen(hi * wid, '#'), cursor (0),
                                                height(hi), width(wid) { }

Screen<24,80> hp2621;

Nontype template arguments must be compile-time constant expressions.

3. Friend Declarations in Class Templates

(1) A friend declaration for an ordinary nontemplate class or function, which grants friendship to the specific named class or function.

template <class Type> class Bar {
    // grants access to ordinary, nontemplate class and function
    friend class FooBar;
    friend void fcn();
    // ...
};

(2) A friend declaration for a class template or function template, which grants access to all instances of the friend.

template <class Type> class Bar {
    // grants access to Foo1 or templ_fcn1 parameterized by any type
    template <class T> friend class Foo1;
    template <class T> friend void templ_fcn1(const T&);
// ...
};

(3) A friend declaration that grants access only to a specific instance of a class or function template.

template <class T> class Foo2;
template <class T> void templ_fcn2(const T&);
template <class Type> class Bar {
    // grants access to a single specific instance parameterized by char*
    friend class Foo2<char*>;
    friend void templ_fcn2<char*>(char* const &);
    // ...
};

More common are friend declarations of the following form:

template <class T> class Foo3;
template <class T> void templ_fcn3(const T&);
template <class Type> class Bar {
    // each instantiation of Bar grants access to the
    // version of Foo3 or templ_fcn3 instantiated with the same type
    friend class Foo3<Type>;
    friend void templ_fcn3<Type>(const Type&);
    // ...
    };

4. Declaration Dependencies

When we grant access to all instances of a given template, there need not be a declaration for that class or function template in scope. Essentially, the compiler treats the friend declaration as a declaration of the class or function as well. When we want to restrict friendship to a specific instantiation, then the class or function must have been declared before it can be used in a friend declaration:

template <class T> class A;
template <class T> class B {
    public:
        friend class A<T>; // ok: A is known to be a template
        friend class C; // ok: C must be an ordinary, nontemplate class
        template <class S> friend class D; // ok: D is a template
        friend class E<T>; // error: E wasn't declared as a template
        friend class F<int>; // error: F wasn't declared as a template
};

5. Making a Function Template a Friend

// function template declaration must precede friend declaration in QueueItem
template <class T>
std::ostream& operator<<(std::ostream&, const Queue<T>&);

template <class T> class Queue;

template <class Type> class QueueItem {
    friend class Queue<Type>;
    // needs access to item and next
    friend std::ostream&
        operator<< <Type> (std::ostream&, const Queue<Type>&);
    // ...
};

template <class Type> class Queue {
    // needs access to head
    friend std::ostream&
        operator<< <Type> (std::ostream&, const Queue<Type>&);
};

1. Template Compilation Models

When the compiler sees a template definition, it does not generate code immediately. The compiler produces type-specific instances of the template only when it sees a use of the template, such as when a function template is called or an object of a class template is defined.

Ordinarily, when we call a function, the compiler needs to see only a declaration for the function. Similarly, when we define an object of class type, the class definition must be available, but the definitions of the member functions need not be present. As a result, we put class definitions and function declarations in header files and definitions of ordinary and class-member functions in source files.

Templates are different: To generate an instantiation, the compiler must have access to the source code that defines the template. When we call a function template or a member function of a class template, the compiler needs the function definition. It needs the code we normally put in the source files.

Standard C++ defines two models for compiling template code: inclusion compilation model and separate compilation model . Class definitions and function declarations go in header files, and function and member definitions go in source files. The two models differ in how the definitions from the source files are made available to the compiler.

2. Inclusion Compilation Model

In the inclusion compilation model , the compiler must see the definition for any template that is used. Typically, we make the definitions available by adding a #include directive to the headers that declare function or class templates. That #include brings in the source file(s) that contain the associated definitions:

// header file utlities.h
#ifndef UTLITIES_H
#define UTLITIES_H
template <class T> int compare(const T&, const T&);
#include "utilities.cc" // get the definitions for compare etc.
#endif

// implemenatation file utlities.cc
template <class T> int compare(const T &v1, const T &v2)
{
    if (v1 < v2) return -1;
    if (v2 < v1) return 1;
    return 0;
}

Some, especially older, compilers that use the inclusion model may generate multiple instantiations. If two or more separately compiled source files use the same template, these compilers will generate an instantiation for the template in each file. Ordinarily, this approach implies that a given template will be instantiated more than once. At link time, or during a prelink
phase, the compiler selects one instantiation, discarding the others. In such cases, compile-time performance can be significantly degraded if there are a lot of files that instantiate the same template. Such compilers often support mechanisms that avoid the compile-time overhead implicit in multiple instantiations of the same template. If compile time for programs using templates is too burdensome, consult your compiler’s user’s guide to see what support your compiler offers to avoid redundant instantiations.

3. Separate Compilation Model

In the separate compilation model , the compiler keeps track of the associated template definitions for us. However, we must tell the compiler to remember a given template definition. We use the export keyword to do so. A template may be defined as exported only once in a program. The declaration for this function template, should, as usual, be put in a header. The declaration must not specify export.

// **.h
template<typename Type> Type sum(Type t1, Type t2);

// **.cpp
export template <typename Type>
Type sum(Type t1, Type t2) {}

Using export on a class template is a bit more complicated. As usual, the class declaration must go in a header file. The class body in the header should not use the export keyword. If we used export in the header, then that header could be used by only one source file in the program.

// class template header goes in shared header file
template <class Type> class Queue { ... };
// Queue.ccimplementation file declares Queue as exported
export template <class Type> class Queue;
#include "Queue.h"
// Queue member definitions

The members of an exported class are automatically declared as exported. It is also possible to declare individual members of a class template as exported. In this case, the keyword export is not specified on the class template itself. It is specified only on the specific member definitions to be exported. The definition of exported member functions need not be visible when the member is used. The definitions of any nonexported member must be treated as in the inclusion model: The definition should be placed inside the header that defines the class template.

4. Class Template Members

Class QueueItem is a private classit has no public interface. We intend this class to be used to implement Queue and have not built it for general use. Hence, it has no public members. We’ll need to make class Queue a friend of QueueItem so that its members can access the members of QueueItem.

Inside the scope of a class template, we may refer to the class using its unqualified name.

template <class Type> class QueueItem {
    // private class: no public section
    QueueItem(const Type &t): item(t), next(0) { }
    Type item; // value stored in this element
    QueueItem *next; // pointer to next element in the Queue
};

template <class Type> 
class Queue 
{
    public:
        // empty Queue
        Queue(): head(0), tail(0) { }
        // copy control to manage pointers to QueueItems in the Queue
        Queue(const Queue &Q): head(0), tail(0)
        { copy_elems(Q); }
        Queue& operator=(const Queue&);
        ~Queue() { destroy(); }
        // return element from head of Queue
        // unchecked operation: front on an empty Queue is undefined
        Type& front() { return head->item; }
        const Type &front() const { return head->item; }
        void push(const Type &); // add element to back of Queue
        void pop (); // remove element from head of Queue
        bool empty () const { // true if no elements in the Queue
            return head == 0;
        }

    private:
        QueueItem<Type> *head; // pointer to first element in Queue
        QueueItem<Type> *tail; // pointer to last element in Queue
        // utility functions used by copy constructor, assignment, and destructor
        void destroy(); // delete all the elements
        void copy_elems(const Queue&); // copy elements from parameter
};

Ordinarily, when we use the name of a class template, we must specify the template parameters. There is one exception to this rule: Inside the scope of the class itself, we may use the unqualified name of the class template. For example, in the declarations of the default and copy constructor the name Queue is a shorthand notation that stands for Queue. Hence,
the copy constructor definition is really equivalent to writing:

Queue<Type>(const Queue<Type> &Q): head(0), tail(0)
    { copy_elems(Q); }

The compiler performs no such inference for the template parameter(s) for other templates used within the class. Hence, we must specify the type parameter when declaring pointers to the companion QueueItem class:

QueueItem<Type> *head; // pointer to first element in Queue
QueueItem<Type> *tail; // pointer to last element in Queue

1. Instantiation

A template is a blueprint; it is not itself a class or a function. The compiler uses the template to generate type-specific versions of the specified class or function. The process of generatng a type-specific instance of a template is known as instantiation. The term reflects the notion that a new “instance” of the template type or function is created.

A template is instantiated when we use it. A class template is instantiated when we refer to the an actual template class type, and a function template is instantiated when we call it or use it to initialize or assign to a pointer to function.

When we want to use a class template, we must always specify the template arguments explicitly. When we use a function template, the compiler will usually infer the template arguments for us.

2.Template Argument Deduction

To determine which functions to instantiate, the compiler looks at each argument. If the corresponding parameter was declared with a type that is a type parameter, then the compiler infers the type of the parameter from the type of the argument. The process of determining the types and values of the template arguments from the type of the function arguments is called template argument deduction. note: Multiple Type Parameter Arguments Must Match Exactly.

3.Limited Conversions on Type Parameter Arguments

short s1, s2;
int i1, i2;
compare(i1, i2); // ok: instantiate compare(int, int)
compare(s1, s2); // ok: instantiate compare(short, short)

In general, arguments are not converted to match an existing instantiation; instead, a new instance is generated. There are only two kinds of conversions that the compiler will perform rather than generating a new instantiation:

• const conversions: A function that takes a reference or pointer to a const can be called with a reference or pointer to non const object, respectively, without generating a new instantiation. If the function takes a nonreference type, then const is ignored on either the parameter type or the argument. That is, the same instantiation will be used whether we pass a const or non const object to a function defined to take a nonreference type.
• array or function to pointer conversions: If the template parameter is not a reference type, then the normal pointer conversion will be applied to arguments of array or function type. An array argument will be treated as a pointer to its first element, and a function argument will be treated as a pointer to the function’s type.

template <typename T> T fobj(T, T); // arguments are copied
template <typename T>
T fref(const T&, const T&); // reference arguments
string s1("a value");
const string s2("another value");
fobj(s1, s2); // ok: calls f(string, string), const is ignored
fref(s1, s2); // ok: non const object s1 converted to const reference
int a[10], b[42];
fobj(a, b); // ok: calls f(int*, int*)
fref(a, b); // error: array types don't match; arguments aren't converted to pointers

4.Template Argument Deduction and Function Pointers

template <typename T> int compare(const T&, const T&);
// pf1 points to the instantiation int compare (const int&, const int&)
int (*pf1) (const int&, const int&) = compare;

It is an error if the template arguments cannot be determined from the function pointer type.

void func(int(*) (const string&, const string&));
void func(int(*) (const int&, const int&));
func(compare); // error: which instantiation of compare?

5.Function-Template Explicit Arguments

In some situations, it is not possible to deduce the types of the template arguments. In such situations, it is necessary to override the template argument deduction mechanism and explicitly specify the types or values to be used for the template
parameters.

Consider the following problem. We wish to define a function template called sum that takes arguments of two differnt types. We’d like the return type to be large enough to contain the sum of two values of any two types passed in any order. How can we do that? How should we specify sum’s return type?

// T or U as the returntype?
template <class T, class U> ??? sum(T, U);

// neither T nor U works as return typ
sum(3, 4L); // second type is larger; want U sum(T, U)
sum(3L, 4); // first type is larger; want T sum(T, U)

An alternative way to specify the return type is to introduce a third template parameter that must be explicitly specified by our caller. We supply an explicit template argument to a call in much the same way that we define an instance of a class template.

template <class T1, class T2, class T3>
T1 sum(T2, T3);

// ok T1 explicitly specified; T2 and T3 inferred from argument types
long val3 = sum<long>(i, lng); // ok: calls long sum(int, long)

Explicit template argument(s) are matched to corresponding template parameter(s) from left to right; the first template argument is matched to the first template parameter. An explicit template argument may be omitted only for the trailing (rightmost) parameters, assuming these can be deduced from the function parameters. If our sum function had been written as

template <class T1, class T2, class T3>
T3 alternative_sum(T2, T1);

// error: can't infer initial template parameters
long val3 = alternative_sum<long>(i, lng);
// ok: All three parameters explicitly specified
long val2 = alternative_sum<long, int, long>(i, lng);

Another example where explicit template arguments would be useful is the ambiguous program

template <typename T> int compare(const T&, const T&);
// overloaded versions of func; each take a different function pointer type
void func(int(*) (const string&, const string&));
void func(int(*) (const int&, const int&));
func(compare<int>); // ok: explicitly specify which version of compare

We saw that the arguments to the version of compare that has a single template type parameter must match exactly. If we wanted to call the function with compatible types, such as int and short, we could use an explicit template argument to specify either int or short as the parameter type. Write a program that uses the version of compare that has one template parameter. Call compare using an explicit template argument that will let you pass arguments of type int and short.

short sval = 123;
int ival = 2;
compare(static_cast<int>(sval), ival);
compare(static_cast<short>(ival), sval);
compare<int>(sval, ival);
compare<short>(sval, ival);

1.Template Parameter List

A template parameter can be a type parameter, which represents a type, or a nontype parameter , which represents a constant expression. A nontype parameter is declared following a type specifier. A type parameter is defined following the keyword class or typename.

The only meaning we can ascribe to a template parameter is to distinguish whether the parameter is a type parameter or a nontype parameter. If it is a type parameter, then we know that the parameter represents an as yet unknown type. If it is a nontype parameter, we know it is an as yet unknown value.

2.inline Function Templates

A function template can be declared inline in the same way as a nontemplate function. The specifier is placed following the template parameter list and before the return type. It is not placed in front of the template keyword.

// ok: inline specifier follows template parameter list
template <typename T> inline T min(const T&, const T&);
// error: incorrect placement of inline specifier
inline template <typename T> T min(const T&, const T&);

3.Using a Function Template

template <typename T>
int compare(const T &v1, const T &v2)
{
    if (v1 < v2) return -1;
    if (v2 < v1) return 1;
    return 0;
}

When we called compare on two string s, we passed two string objects, which we initialized from string literals
What would happen if we wrote: compare ("hi", "world").该代码会出现编译错误。因为引用的缘故，根据”hi”可将模板形参推断为char[3]，根据”world”可将模板形参推断为char[6]，T被推断为不同的类型。、

4.Designating Types inside the Template Definition

In addition to defining data or function members, a class may define type members. When we want to use such types inside a
function template, we must tell the compiler that the name we are using refers to a type. We must be explicit because the compiler (and a reader of our program) cannot tell by inspection when a name defined by a type parameter is a type or a value. As an example, consider the following function:

template <class Parm, class U>
Parm fcn(Parm* array, U value)
{
    Parm: :size_type * p;   // If Parm::size_type is a type, then a declaration
                            // If Parm::size_type is an object, then multiplication
}

We know that size_type must be a member of the type bound to Parm , but we do not know whether size_type is the name of a type or a data member. By default, the compiler assumes that such names name data members, not types. If we want the compiler to treat size_type as a type, then we must explicitly tell the compiler to do so:

template <class Parm, class U>
Parm fcn(Parm* array, U value)
{
    typename Parm::size_type * p; // ok: declares p to be a pointer
}

5.Question

Write a function template that takes a pair of values that represent iterators of unknown type. Find the value that occurs most frequently in the sequence.

template<typename T>
typename T::value_type find_most(T begin, T end)
{
    T most_iter;
    size_t max_num, num;
    map<typename T::value_type, size_t> container;

    max_num = 0;
    while(begin != end)
    {
        num = ++container[*begin];
        if(num > max_num)
        {
            max_num = num;
            most_iter = begin;
        }

        ++begin;
    }

    return *most_iter;
}

6. Nontype Template Parameters

The function itself takes a single parameter, which is a reference to an array

template <class T, size_t N> void array_init(T (&parm)[N])
{
    for (size_t i = 0; i != N; ++i) {
        parm[i] = 0;
    }
}
int x[42];
double y[10];
array_init(x); // instantiates array_init(int(&)[42])
array_init(y); // instantiates array_init(double(&)[10])

A template nontype parameter is a constant value inside the template definition. A nontype parameter can be used when constant expressions are required.

// Another example: Write a function template that can determine the size of an array.
template<typename T, size_t N>
size_t size(T (&array)[N])
{
    return N;
}

7. Writing Generic Programs

The operations performed inside a function template constrains the types that can be used to instantiate the function. It is up to the programmer to guarantee that the types used as the function arguments actually support any operations that are used, and that
those operations behave correctly in the context in which the template uses them.

When writing template code, it is useful to keep the number of requirements placed on the argument types as small as possible.Simple though it is, our compare function illustrates two important principles for writing generic code:

• The parameters to the template are const references.
• The tests in the body use only < comparisons.

By making the parameters const references, we allow types that do not allow copying. Moreover, if compare is called with large objects, then this design will also make the function run faster. we reduce the requirements on types that can be used with our compare function. Those types must support < , but they need not also support > .

1.Template Parameter List

A template parameter can be a type parameter, which represents a type, or a nontype parameter , which represents a constant expression. A nontype parameter is declared following a type specifier. A type parameter is defined following the keyword class or typename.

The only meaning we can ascribe to a template parameter is to distinguish whether the parameter is a type parameter or a nontype parameter. If it is a type parameter, then we know that the parameter represents an as yet unknown type. If it is a nontype parameter, we know it is an as yet unknown value.

2.inline Function Templates

A function template can be declared inline in the same way as a nontemplate function. The specifier is placed following the template parameter list and before the return type. It is not placed in front of the template keyword.

// ok: inline specifier follows template parameter list
template <typename T> inline T min(const T&, const T&);
// error: incorrect placement of inline specifier
inline template <typename T> T min(const T&, const T&);

3.Using a Function Template

template <typename T>
int compare(const T &v1, const T &v2)
{
    if (v1 < v2) return -1;
    if (v2 < v1) return 1;
    return 0;
}

When we called compare on two string s, we passed two string objects, which we initialized from string literals
What would happen if we wrote: compare ("hi", "world").该代码会出现编译错误。因为引用的缘故，根据”hi”可将模板形参推断为char[3]，根据”world”可将模板形参推断为char[6]，T被推断为不同的类型。、

4.Designating Types inside the Template Definition

In addition to defining data or function members, a class may define type members. When we want to use such types inside a
function template, we must tell the compiler that the name we are using refers to a type. We must be explicit because the compiler (and a reader of our program) cannot tell by inspection when a name defined by a type parameter is a type or a value. As an example, consider the following function:

template <class Parm, class U>
Parm fcn(Parm* array, U value)
{
    Parm: :size_type * p;   // If Parm::size_type is a type, then a declaration
                            // If Parm::size_type is an object, then multiplication
}

We know that size_type must be a member of the type bound to Parm , but we do not know whether size_type is the name of a type or a data member. By default, the compiler assumes that such names name data members, not types. If we want the compiler to treat size_type as a type, then we must explicitly tell the compiler to do so:

template <class Parm, class U>
Parm fcn(Parm* array, U value)
{
    typename Parm::size_type * p; // ok: declares p to be a pointer
}

5.Question

Write a function template that takes a pair of values that represent iterators of unknown type. Find the value that occurs most frequently in the sequence.

template<typename T>
typename T::value_type find_most(T begin, T end)
{
    T most_iter;
    size_t max_num, num;
    map<typename T::value_type, size_t> container;

    max_num = 0;
    while(begin != end)
    {
        num = ++container[*begin];
        if(num > max_num)
        {
            max_num = num;
            most_iter = begin;
        }

        ++begin;
    }

    return *most_iter;
}

6. Nontype Template Parameters

The function itself takes a single parameter, which is a reference to an array

template <class T, size_t N> void array_init(T (&parm)[N])
{
    for (size_t i = 0; i != N; ++i) {
        parm[i] = 0;
    }
}
int x[42];
double y[10];
array_init(x); // instantiates array_init(int(&)[42])
array_init(y); // instantiates array_init(double(&)[10])

A template nontype parameter is a constant value inside the template definition. A nontype parameter can be used when constant expressions are required.

// Another example: Write a function template that can determine the size of an array.
template<typename T, size_t N>
size_t size(T (&array)[N])
{
    return N;
}

7. Writing Generic Programs

The operations performed inside a function template constrains the types that can be used to instantiate the function. It is up to the programmer to guarantee that the types used as the function arguments actually support any operations that are used, and that
those operations behave correctly in the context in which the template uses them.

When writing template code, it is useful to keep the number of requirements placed on the argument types as small as possible.Simple though it is, our compare function illustrates two important principles for writing generic code:

• The parameters to the template are const references.
• The tests in the body use only < comparisons.

By making the parameters const references, we allow types that do not allow copying. Moreover, if compare is called with large objects, then this design will also make the function run faster. we reduce the requirements on types that can be used with our compare function. Those types must support < , but they need not also support > .

1. Containers and Inheritance

We’d like to use containers (or built-in arrays) to hold objects that are related by inheritance. However, the fact that objects are not polymorphic affects how we can use containers with types in an inheritance hierarchy. Because derived objects are “sliced down” when assigned to a base object, containers and types related by inheritance do not mix well.

The only viable alternative would be to use the container to hold pointers to our objects. This strategy works, but at the cost of pushing onto our users the problem of managing the objects and pointers. The user must ensure that the objects pointed to stay around for as long as the container. If the objects are dynamically allocated, then the user must ensure that they are properly freed when the container goes away.

2. Handle Classes and Inheritance

One of the ironies of object-oriented programming in C++ is that we cannot use objects to support polymorphism. Instead, we must use pointers and references, not objects. Unfortunately, using pointers or references puts a burden on the users of our classes.

A common technique in C++ is to define a so-called handle class . The handle class stores and manages a pointer to the base class. The type of the object to which that pointer points will vary; it can point at either a base- or a derived-type object. Users access the operations of the inheritance hierarchy through the handle. Because the handle uses its pointer to execute those operations, the behavior of virtual members will vary at run time depending on the kind of object to which the handle is actually bound. Users of the handle thus obtain dynamic behavior but do not themselves have to worry about managing the pointer.

3. A Pointerlike Handle

We’ll define a pointerlike handle class, named Sales_item , to represent our Item_base hierarchy. Users of Sales_item will use it as if it were a pointer: Users will bind a Sales_item to an object of type Item_base and will then use the * and -> operations to execute Item_base operations:

// bind a handle to a Bulk_item object
Sales_item item(Bulk_item("0-201-82470-1", 35, 3, .20));
item->net_price(); // virtual call to net_price function

However, users won’t have to manage the object to which the handle points; the Sales_item class will do that part of the job. When users call a function through a Sales_item , they’ll get polymorphic behavior.

The use-counted classes we’ve used so far have used a companion class to store the pointer and associated use count. In this class, we’ll use a different design. The Sales_item class will have two data members, both of which are pointers: One pointer will point to the Item_base object and the other will point to the use count. The Item_base pointer might point to an Item_base object or an object of a type derived from Item_base.

class Sales_item {
    public:
        // default constructor: unbound handle
        Sales_item(): p(0), use(new std::size_t(1)) { }
        // attaches a handle to a copy of the Item_base object
        Sales_item(const Item_base&);
        // copy control members to manage the use count and pointers
        Sales_item(const Sales_item &i):
                        p(i.p), use(i.use) { ++*use; }
        ~Sales_item() { decr_use(); }
        Sales_item& operator=(const Sales_item&);
        // member access operators
        const Item_base *operator->() const { if (p) return p;
            else throw std::logic_error("unbound Sales_item"); }
        const Item_base &operator*() const { if (p) return *p;
            else throw std::logic_error("unbound Sales_item"); }
    private:
        Item_base *p; // pointer to shared item
        std::size_t *use; // pointer to shared use count
        // called by both destructor and assignment operator to free pointers
        void decr_use()
        { if (--*use == 0) { delete p; delete use; } }
};

Sales_item&
Sales_item::operator=(const Sales_item &rhs)
{
    ++*rhs.use;
    decr_use();
    p = rhs.p;
    use = rhs.use;
    return *this;
}

Sales_item(const Item_base&);The constructor will allocate a new object of the appropriate type and copy the parameter into that newly allocated object. That way the Sales_item class will own the object and can guarantee that the object is not deleted until the last Sales_item attached to the object goes away. To implement the constructor that takes an Item_base , we must first solve a problem: We do not know the actual type of the object that the constructor is given. We know that it is an Item_base or an object of a type derived from Item_base. The common approach to solving this problem is to define a virtual operation to do the copy, which we’ll name clone.

class Item_base {
    public:
        virtual Item_base* clone() const
        { return new Item_base(*this); }
};
class Bulk_item : public Item_base {
    public:
        Bulk_item* clone() const
        { return new Bulk_item(*this); }
};

Sales_item::Sales_item(const Item_base &item):
        p(item.clone()), use(new std::size_t(1)) { }

If the base instance of a virtual function returns a reference or pointer to a class type, the derived version of the virtual may return a class publicly derived from the class returned by the base class instance (or a pointer or a reference to a class type).

1. Using a Derived Object to Initialize or Assign a Base Object

Because there is a conversion from reference to derived to reference to base, these copy-control members can be used to initialize or assign a base object from a derived object:

Item_base item; // object of base type
Bulk_item bulk; // object of derived type
// ok: uses Item_base::Item_base(const Item_base&) constructor
Item_base item(bulk); // bulk is "sliced down" to its Item_base portion
// ok: calls Item_base::operator=(const Item_base&)
item = bulk; // bulk is "sliced down" to its Item_base portion

When we call the Item_base copy constructor or assignment operator on an object of type Bulk_item , the following steps happen:

• The Bulk_item object is converted to a reference to Item_base, which means only that an Item_base reference is bound to the Bulk_item object.
• That reference is passed as an argument to the copy constructor or assignment operator.
• Those operators use the Item_base part of Bulk_item to initialize and assign, respectively, the members of the Item_base on which the constructor or assignment was called.
• Once the operator completes, the object is an Item_base . It contains a copy of the Item_base part of the Bulk_item from which it was initialized or assigned, but the Bulk_item parts of the argument are ignored.

2. Defining a Default Constructor

Item_base(const std::string &book = "", double sales_price = 0.0): 
                                    isbn(book), price(sales_price) { }

class Bulk_item : public Item_base {
    public:
        Bulk_item(): min_qty(0), discount(0.0) { }
        // as before
};

This constructor uses the constructor initializer list to initialize its min_qty and discount members. The constructor initializer also implicitly invokes the Item_base default constructor to initialize its base-class part. The effect of running this constructor is that first the Item_base part is initialized using the Item_base default constructor. That constructor sets isbn to the empty string and price to zero. After the Item_base constructor finishes, the members of the Bulk_item part are initialized, and the (empty) body of the constructor is executed.
The constructor initializer list supplies initial values for a class’ base class and members. It does not specify the order in which those initializations are done. The base class is initialized first and then the members of the derived class are initialized in the order in which they are declared.
A class may initialize only its own immediate base class. An immediate base class is the class named in the derivation list.

3. Defining a Derived Copy Constructor

If a derived class explicitly defines its own copy constructor or assignment operator, that definition completely overrides the
defaults. The copy constructor and assignment operator for inherited classes are responsible for copying or assigning their base-
class components as well as the members in the class itself.

class Base { /* ... */ };
class Derived: public Base {
    public:
        // Base::Base(const Base&) not invoked automatically
        Derived(const Derived& d):
            Base(d) /* other member initialization */ { /*... */ }
};

The initializer Base(d) converts the derived object, d , to a reference to its base part and invokes the base-class copy constructor. Had the initializer for the base class been omitted,

Derived(const Derived& d) /* derived member initizations */
{/* ... */ }

the effect would be to run the Base default constructor to initialize the base part of the object. Assuming that the initialization of the Derived members copied the corresponding elements from d , then the newly constructed object would be oddly configured: Its Base part would hold default values, while its Derived members would be copies of another object.

4. Derived-Class Assignment Operator

If the derived class defines its own assignment operator, then that operator must assign the base part explicitly:

// Base::operator=(const Base&) not invoked automatically
Derived &Derived::operator=(const Derived &rhs)
{
    if (this != &rhs) {
        Base::operator=(rhs); // assigns the base part
        // do whatever needed to clean up the old value in the derived part
        // assign the members from the derived
    }
    return *this;
}

5. Derived-Class Destructor

The destructor works differently from the copy constructor and assignment operator: The derived destructor is never responsible for destroying the members of its base objects. The compiler always implicitly invokes the destructor for the base part of a derived object. Objects are destroyed in the opposite order from which they are constructed: The derived destructor is run first, and then the base-class destructors are invoked, walking back up the inheritance hierarchy.
The root class of an inheritance hierarchy should define a virtual destructor even if the destructor has no work to do.

6. Virtuals in Constructors and Destructors

A derived object is constructed by first running a base-class constructor to initialize the base part of the object. While the base-class constructor is executing, the derived part of the object is uninitialized. In effect, the object is not yet a derived object.

When a derived object is destroyed, its derived part is destroyed first, and then its base parts are destroyed in the reverse order of how they were constructed.

In both cases, while a constructor or destructor is running, the object is incomplete. To accommodate this incompleteness, the compiler treats the object as if its type changes during construction or destruction. Inside a base-class constructor or destructor, a derived object is treated as if it were an object of the base type.

If a virtual is called from inside a constructor or destructor, then the version that is run is the one defined for the type of the constructor or destructor itself.

7. Name Collisions and Inheritance

A derived-class member with the same name as a member of the base class hides direct access to the base-class member. We can access a hidden base-class member by using the scope operator. The derived-class member hides the base-class member within the scope of the derived class. The base member is hidden, even if the prototypes of the functions differ :

struct Base {
    int memfcn();
};
struct Derived : Base {
    int memfcn(int); // hides memfcn in the base
};
Derived d; Base b;
b.memfcn(); // calls Base::memfcn
d.memfcn(10); // calls Derived::memfcn
d.memfcn(); // error: memfcn with no arguments is hidden
d.Base::memfcn(); // ok: calls Base::memfcn

8. Name Lookup and Inheritance

Understanding how function calls are resolved is crucial to understanding inheritance hierarchies in C++. The following four steps are followed:

• Start by determining the static type of the object, reference, or pointer through which the function is called.
• Look for the function in that class. If it is not found, look in the immediate base class and continue up the chain of classes until either the function is found or the last class is searched. If the name is not found in the class or its enclosing base classes, then the call is in error.
• Once the name is found, do normal type-checking to see if this call is legal given the definition that was found.
• Assuming the call is legal, the compiler generates code. If the function is virtual and the call is through a reference or pointer, then the compiler generates code to determine which version to run based on the dynamic type of the object. Otherwise, the compiler generates code to call the function directly.

1. protected Members

protected has important property: A derived object may access the protected members of its base class only through a derived
object. The derived class has no special access to the protected members of base type objects. 这里说的情况是在Bulk_item的成员函数里面。如果是在user code代码里面，protected属性的成员肯定是不能访问的。

void Bulk_item::memfcn(const Bulk_item &d, const Item_base &b)
{
    // attempt to use protected member
    double ret = price; // ok: uses this->price
    ret = d.price; // ok: uses price from a Bulk_item object
    ret = b.price; // error: no access to price from an Item_base
}

2. Derived Classes and virtual Functions

If a derived class does not redefine a virtual, then the version it uses is the one defined in its base class. A derived type must include a declaration for each inherited member it intends to redefine.
With one exception, the declaration of a virtual function in the derived class must exactly match the way the function is defined in the base. That exception applies to virtuals that return a reference (or pointer) to a type that is itself a base class. A virtual function in a derived class can return a reference (or pointer) to a class that is publicly derived from the type returned by the base-class function.

3. Overriding the Virtual Mechanism

In some cases, we want to override the virtual mechanism and force a call to use a particular version of a virtual function. We can do so by using the scope operator:

Item_base *baseP = &derived;
// calls version from the base class regardless of the dynamic type of baseP
double d = baseP->Item_base::net_price(42);

This code forces the call to net_price to be resolved to the version defined in Item_base . The call will be resolved at compile time. When a derived virtual calls the base-class version, it must do so explicitly using the scope operator. If the derived function neglected to do so, then the call would be resolved at run time and would be a call to itself, resulting in an infinite recursion.

4. 无题

A publicly derived class inherits the interface of its base class; it has the same interface as its base class. In well-designed class hierarchies, objects of a publicly derived class can be used wherever an object of the base class is expected. By far the most common form of inheritance is public.

5. restore the access level of an inherited member

class Base {
    public:
        std::size_t size() const { return n; }
    protected:
    std::size_t n;
};
class Derived : private Base { . . . };

In this hierarchy, size is public in Base but private in Derived. To make size public in Derived we can add a using declaration for it to a public section in Derived. By changing the definition of Derived as follows, we can make the size member accessible to users and n accessible to classes subsequently derived from Derived:

class Derived : private Base {
    public:
        // maintain access levels for members related to the size of the object
        using Base::size;
    protected:
        using Base::n;
        // ...
};

The derived class can restore the access level of an inherited member. The access level cannot be made more or less restrictive than the level originally specified within the base class.

6. Default Inheritance Protection Levels

A derived class defined using the class keyword has private inheritance. A class is defined with the struct keyword, has public inheritance.The only differences between class and struct are the default protection level for members and the default protection level for a derivation.

class Base { /* ... */ };
struct D1 : Base { /* ... */ }; // public inheritance by default
class D2 : Base { /* ... */ }; // private inheritance by default

linux下最大文件描述符的限制有两个方面，一个是进程级的限制，另外一个则是系统级限制。

1. 系统级的限制

/proc/sys/fs/file-max是系统中的所有进程总共可以同时打开的文件数量，可以通过修改内核参数来更改该限制：sysctl -w fs.file-max=102400。但是，使用sysctl命令更改是临时的，如果想永久更改需要在/etc/sysctl.conf添加fs.file-max=102400，保存退出后使用sysctl -p 命令使其生效。

/proc/sys/fs/file-max：This file defines a system-wide limit on the number of open files for all processes. (See also setrlimit(2), which can be used by a process to set the per-process limit, RLIMIT_NOFILE, on the number of files it may open.) If you get lots of error messages about running out of file handles, try increasing this value: echo 100000 > /proc/sys/fs/file-max. The kernel constant NR_OPEN imposes an upper limit on the value that may be placed in file-max. If you increase /proc/sys/fs/file-max, be sure to increase /proc/sys/fs/inode-max to 3-4 times the new value of /proc/sys/fs/file-max, or you will run out of inodes.

2. 进程级的限制

修改一个进程能够同时打开的文件数量限制有两种方式：(1)通过bash的内置命令ulimit (2)在程序中调用setrlimit函数

(1)ulimit is a bash built_in command. It provides control over the resources available to the shell and to processes started by it.
执行ulimit -n命令可以看到本次登录的shell会话的文件描述符的限制，一般情况下是1024。当然可以通过ulimit -SHn 102400 命令来修改该限制。
(2) The getrlimit() and setrlimit() system calls get and set resource limits respectively. Each resource has an associated soft and hard limit, as defined by the rlimit structure:

struct rlimit {
    rlim_t rlim_cur;  /* Soft limit */
    rlim_t rlim_max;  /* Hard limit (ceiling for rlim_cur) */
};

The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit: an unprivileged process may only set its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit. A privileged process may make arbitrary changes to either limit value. The value RLIM_INFINITY denotes no limit on a resource.

不管通过ulimit还是setrlimit来修改限制，都只能对当前进程及其子进程有效。而且它们都会受到/etc/security/limits.conf文件中的数量限制。如下所示，

vi /etc/security/limits.conf
xiaohua hard nofile 100
xiaohua soft nofile 100

则用户xiaohua的每个进程能够同时打开的文件数量的上限是100，通过ulimit和setrlimit的修改的上限值不能超过它。而且可以看出，其实/etc/security/limits.conf是用户级的限制，能够限制某个用户或者用户组的每个进程能够同时打开的文件数量的上限。修改该文件，保存退出后重新登录，里面设置的值才会生效。

1. 查看linux内核版本

方法一：
        命令： uname -a // uname is short for unix name
        作用： 查看系统内核版本号及系统名称
方法二：
        命令： cat /proc/version
        作用： 查看目录”/proc”下version的信息，也可以得到当前系统的内核版本号及系统名称

补充说明：／proc文件系统，它不是普通的文件系统，而是系统内核的映像。The proc file system is a pseudo-file system which is used as an interface to kernel data structures. It is commonly mounted at /proc. Most of it is read-only, but some files allow kernel variables to be changed. 我们使用命令“uname -a”的信息就是从该文件获取的。

2. 查看进程打开的所有文件描述符

方法一：ll /proc/<进程PID>/fd/
方法二：lsof -p <进程PID>

3. 设置和查看系统资源限制ulimit

ulimit(short for user limits): it provides control over the resources available to the shell and to processes started by it.

Syntax
      ulimit [-acdfHlmnpsStuv] [limit]

Options

   -S   Change and report the soft limit associated with a resource. 
   -H   Change and report the hard limit associated with a resource. 

   -a   All current limits are reported. 
   -c   The maximum size of core files created. 
   -d   The maximum size of a process's data segment. 
   -f   The maximum size of files created by the shell(default option) 
   -l   The maximum size that can be locked into memory. 
   -m   The maximum resident set size. 
   -n   The maximum number of open file descriptors. 
   -p   The pipe buffer size. 
   -s   The maximum stack size. 
   -t   The maximum amount of cpu time in seconds. 
   -u   The maximum number of processes available to a single user. 
   -v   The maximum amount of virtual memory available to the process.

ulimit 作为对资源使用限制的一种工作，是有其作用范围的。那么，它限制的对象是单个用户，单个进程，还是整个系统呢？事实上，ulimit 限制的是当前shell进程以及其派生的子进程。举例来说，如果用户同时运行了两个shell终端进程，只在其中一个环境中执行了ulimit –f 100，则该shell进程里创建文件的大小受到相应的限制，而同时另一个shell终端包括其上运行的子程序都不会受其影响。

那么，是否有针对某个具体用户的资源加以限制的方法呢？答案是有的，方法是通过修改系统的 /etc/security/limits 配置文件。该文件不仅能限制指定用户的资源使用，还能限制指定组的资源使用。该文件的每一行都是对限定的一个描述，格式如下：
<domain> <type> <item> <value>
domain 表示用户或者组的名字，还可以使用 * 作为通配符。type 可以有两个值，soft 和 hard。item 则表示需要限定的资源，可以有很多候选值，如 stack，cpu，nofile 等等，分别表示最大的堆栈大小，占用的 cpu 时间，以及打开的文件数。通过添加对应的一行描述，则可以产生相应的限制。例如：
* hard nofile 100
该行配置语句限定了任意用户所能创建的最大文件数是100。

现在已经可以对进程和用户分别做资源限制了，看似已经足够了，其实不然。很多应用需要对整个系统的资源使用做一个总的限制，这时候我们需要修改 /proc 下的配置文件。/proc 目录下包含了很多系统当前状态的参数，例如 /proc/sys/kernel/pid_max，/proc/sys/net/ipv4/ip_local_port_range 等等，从文件的名字大致可以猜出所限制的资源种类。由于该目录下涉及的文件众多，在此不一一介绍。

4. error while loading shared libraries

库文件在链接(静态库和共享库)和运行(仅限于使用共享库的程序，因为静态库已经链接到可执行程序中了)时被使用，其搜索路径是在系统中进行设置的。一般linux系统把 /lib 和 /usr/lib 两个目录作为默认的库搜索路径，所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库，需要将库的位置添加到 库的搜索路径之中。设置库文件的搜索路径有下列两种方式，可任选其一使用：

(1) 修改环境变量LD_LIBRARY_PATH
在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。例如$export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH。并且LD_LIBRARY_PATH路径优先于系统默认路径之前查找
(2) 修改配置文件ld.so.conf
添加方法也极其简单，将库文件的绝对路径直接写进去就OK了，一行一个。例如：
/usr/X11R6/lib
/usr/local/lib
需要注意的是：第二种搜索路径的设置方式对于程序链接时的库(包括共享库和静态库)的定位已经足够了，但是对于使用了共享库的程序的执行还是不够的。这是因为为了加快程序执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率，所以是直接读取库列表文件 /etc/ld.so.cache 从中进行搜索的。/etc/ld.so.cache 是一个非文本的数据文件，不能直接编辑，它是根据 /etc/ld.so.conf 中设置的搜索路径由 /sbin/ldconfig 命令将这些搜索路径下的共享库文件集中在一起而生成的（ldconfig 命令要以 root 权限执行）。

因此，为了保证程序执行时对库的定位，在 /etc/ld.so.conf 中进行了库搜索路径的设置之后，还必须要运行 /sbin/ldconfig 命令更新 /etc/ld.so.cache 文件之后才可以。ldconfig ,简单的说，它的作用就是将/etc/ld.so.conf列出的路径下的库文件缓存到/etc/ld.so.cache 以供使用。因此当安装完一些库文件，(例如刚安装好glib)，或者修改ld.so.conf增加新的库路径后，需要运行一下 /sbin/ldconfig使所有的库文件都被缓存到ld.so.cache中，如果没做，即使库文件明明就在/usr/lib下的，也是不会被使用的，结果编译过程中报错，缺少xxx库，去查看发现明明就在那放着。

在程序链接时，对于库文件（静态库和共享库）的搜索路径，除了上面的设置方式之外，还可以通过 -L 参数显式指定。因为用 -L 设置的路径将被优先搜索，所以在链接的时候通常都会以这种方式直接指定要链接的库的路径。

现代链接器在处理动态库时将 链接时路径（Link-time path）和运行时路径（Run-time path）分开,用户可以通过-L指定链接时库的路径，通过-R（或-rpath）指定程序运行时库的路径，大大提高了库应用的灵活性和搜索库文件的效率。

5. 墙上时钟时间，用户cpu时间，系统cpu时间

时钟时间(墙上时钟时间wall clock time)：从进程从开始运行到结束，时钟走过的时间，这其中包含了进程在阻塞和等待状态的时间。
用户CPU时间：用户进程获得了CPU资源以后，在用户态执行的时间。
系统CPU时间：用户进程获得了CPU资源以后，在内核态的执行时间。

进程的三种状态为阻塞、就绪、运行。

时钟时间 = 阻塞时间 ＋ 就绪时间 ＋ 运行时间
用户CPU时间 = 运行状态下用户空间的时间
系统CPU时间 = 运行状态下内核空间的时间

用户CPU时间 + 系统CPU时间 = 运行时间。

We should set nonblocking mode on all network handles, and use select() or poll() to tell which network handle has data waiting. With this scheme, the kernel tells you whether a file descriptor is ready. It’s particularly important to remember that readiness notification from the kernel is only a hint; the file descriptor might not be ready anymore when you try to read from it. That’s why it’s important to use nonblocking mode when using readiness notification.

select的基本用法不再叙述。select uses descriptor sets, typically an array of integers, with each bit in each integer corresponding to a descriptor. For example, using 32-bit integers, the first element of the array corresponds to descriptors 0 through 31, the second element of the array corresponds to descriptors 32 through 63, and so on. All the implementation details are irrelevant to the application and are hidden in the fd_set datatype and the following four macros:

void FD_ZERO(fd_set *fdset);          /* clear all bits in fdset */
 
void FD_SET(int fd, fd_set *fdset);   /* turn on the bit for fd in fdset */
 
void FD_CLR(int fd, fd_set *fdset);   /* turn off the bit for fd in fdset */
 
int FD_ISSET(int fd, fd_set *fdset);  /* is the bit for fd on in fdset ? */

We allocate a descriptor set of the fd_set datatype, we set and test the bits in the set using these macros, and we can also assign it to another descriptor set across an equals sign (=) in C. The constant FD_SETSIZE, defined by including , is the number of descriptors in the fd_set datatype. Its value is often 1024.

也就是说，使用select有一个限制，那就是它支持的文件描述符的数量，一般是1024。Many implementations have declarations similar to the following, which are taken from the 4.4BSD header:

#ifndef FD_SETSIZE
#define FD_SETSIZE      256
#endif

This makes us think that we can just #define FD_SETSIZE to some larger value before including this header to increase the size of the descriptor sets used by select. Unfortunately, this normally does not work. To see what is wrong, notice that Figure 16.53 of TCPv2 declares three descriptor sets within the kernel and also uses the kernel’s definition of FD_SETSIZE as the upper limit. The only way to increase the size of the descriptor sets is to increase the value of FD_SETSIZE and then recompile the kernel. Changing the value without recompiling the kernel is inadequate.
但是自己在实验的时候，发现输出1024，这是为什么呢？难道编译的是否内核里的宏定义直接覆盖用户提供的。

#include <stdio.h>
#define FD_SETSIZE 512
#include <sys/types.h>

int main()
{
    printf("%d\n", FD_SETSIZE);
}

1、水平触发 VS 边缘触发

水平触发(level-triggered，也被称为条件触发)LT: 只要满足条件，就触发一个事件(只要有数据没有被获取，内核就不断通知你)

边缘触发(edge-triggered)ET: 每当状态变化时，触发一个事件(仅当状态由not ready 到 ready时触发一个事件)
Eedge-triggered readiness notification means you give the kernel a file descriptor, and later, when that descriptor transitions from not ready to ready, the kernel notifies you somehow. It then assumes you know the file descriptor is ready, and will not send any more readiness notifications of that type for that file descriptor until you do something that causes the file descriptor to no longer be ready (e.g. until you receive the EWOULDBLOCK error on a send, recv, or accept call, or a send or recv transfers less than the requested number of bytes). epoll is the recommended edge-triggered poll replacement for the 2.6 Linux kernel.

举个读socket的例子，假定经过长时间的沉默后，现在来了100个字节，这时无论边缘触发和条件触发都会产生一个read ready notification通知应用程序可读。应用程序读了50个字节，然后重新调用api等待io事件。这时水平触发的api会因为还有50个字节可读从 而立即返回用户一个read ready notification。而边缘触发的api会因为可读这个状态没有发生变化而陷入长期等待。 因此在使用边缘触发的api时，要注意每次都要读到socket返回EWOULDBLOCK为止，否则这个socket就算废了。而使用条件触发的api 时，如果应用程序不需要写就不要关注socket可写的事件，否则就会无限次的立即返回一个write ready notification。大家常用的select就是属于水平触发这一类，长期关注socket写事件会出现CPU 100%的毛病。

As is known, some blocking calls like read and write would return -1 and set errno to EINTR, and we need handle this. My question is: Does this apply for non-blocking calls, e.g, set socket to O_NONBLOCK?

答案是：对于非阻塞调用，它们不会返回EINTR错误。 If you take a look at the man pages of various systems for the following socket functions bind(), connect(), send(), and receive(), or look those up in the POSIX standard, you’ll notice something interesting: All these functions except one may return -1 and set errno to EINTR. The one function that is not documented to ever fail with EINTR is bind(). And bind() is also the only function of that list that will never block by default. So it seems that only blocking functions may fail because of EINTR, including read() and write(), yet if these functions never block, they also will never fail with EINTR and if you use O_NONBLOCK, those functions will never block.

Of course, even with non-blocking I/O, the read call may have temporarily interrupted by a signal but why would the system have to indicate that? Every function call, whether this is a system function or one written by the user, may be temporarily interrupted by a signal, really every single one, no exception. If the system would have to inform the user whenever that happens, all system functions could possibly fail because of EINTR. However, even if there was a signal interruption, the functions usually perform their task all the way to the end, that’s why this interruption is irrelevant. The error EINTR is used to tell the caller that the action he has requested was not performed because of a signal interruption, but in case of non-blocking I/O, there is no reason why the function should not perform the read or the write request, unless it cannot be performed right now, but then this can be indicated by an appropriate error(EAGAIN or EWOULDBLOCK ).

To confirm my theory, I took a look at the kernel of MacOS (10.8), which is still largely based on the FreeBSD kernel and it seems to confirm the suspicion. If a read call is currently not possible, as no data are available, the kernel checks for the O_NONBLOCK flag in the file descriptor flags. If this flag is set, it fails immediately with EAGAIN. If it is not set, it puts the current thread to sleep by calling a function named msleep(). This function causes the current thread to sleep until it is explicitly woken up (which is the case if data becomes ready for reading) or a timeout has been hit (e.g. you can set a receive timeout on sockets). Yet the thread is also woken up, if a signal is delivered, in which case msleep() itself returns EINTR and the next higher layer just passes this error through. So it is msleep() that produces the EINTR error, but if the O_NONBLOCK flag is set, msleep() is never called in the first place, hence this error cannot be returned.

When a process writes to a socket that has received an RST, the SIGPIPE signal is sent to the process. 这是UNIX网络编程卷一(5.13章节)中的内容。但是在实际的编程中发现，当套接字收到RST报文段后，第一次read或者write会产生ECONNRESET错误，第二次read或者write时才会触发SIGPIPE信号。这与UNIX网络编程卷一中的描述“当套接字接收到RST后，我们再执行write操作则会触发SIGPIPE信号”不一样。

The default action of this signal is to terminate the process, so the process must catch the signal to avoid being involuntarily terminated. If the process either catches the signal and returns from the signal handler, or ignores the signal, the write operation returns EPIPE. If special actions are needed when the signal occurs (writing to a log file perhaps), then the signal should be caught and any desired actions can be performed in the signal handler.

当客户端进程(例如浏览器)需要同时发起多个连接的时候，如果使用阻塞connect，那么先发起第一个连接并等待它返回，然后第二个，第三……这样效率不高，在等待连接返回的时间内，可以做一些其他的任务处理。而且，如果某个连接因为超时才返回的话，那么客户端进程阻塞在这个连接上的时间将会更多。所以，这种情况下，我们更喜欢非阻塞connect。

在使用非阻塞connect的时候，有以下几点需要注意：
1、When a TCP socket is set to nonblocking and then connect is called, connect returns immediately with an error of EINPROGRESS but the TCP three-way handshake continues.
2、Even though the socket is nonblocking, if the server to which we are connecting is on the same host, the connection is normally established immediately when we call connect.
3、POSIX have the following two rules regarding select and nonblocking connects：(1) When the connection completes successfully, the descriptor becomes writable. (2) When the connection establishment encounters an error, the descriptor becomes both readable and writable.

// 省略 select

FD_ISSET(sockfd, &wset)
{
    int error = 0;
    socklen_t error_len = sizeof(error);

    int ret = getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &error, &error_len);

    if(ret < 0)
    {
        printf("connection error: %s", strerror(errno));
        return -1;
    }
    else
    {
        if(error != 0)
        {
            errno = error;
            printf("connection error: %s", strerror(errno));
            return -1;
        }
        else
        {
            printf("connection success");
            return 0;
        }
    }
}

There are portability problems with various socket implementations and nonblocking connects. If an error occurred, Berkeley-derived implementations of getsockopt return 0 with the pending error returned in our variable error. But Solaris causes getsockopt itself to return –1 with errno set to the pending error.

对于一个阻塞的套接字，当我们调用connect时被信号中断了，它会返回EINTR错误。但是要注意，我们不能对这个套接字再次调用connect，否则将返回EADDRINUSE错误。此时正确的做法是调用select，就像使用非阻塞connect一样。select returns when the connection completes successfully (making the socket writable) or when the connection fails (making the socket readable and writable).