熟读而精思，循序而渐进，厚积而薄发。
我们还知道，类的静态成员函数是不需要绑定到特定对象上面的，所以我们就可以将worker声明为静态成员。
1 2 3 4 5 6 7 8 9 10 11 | class Thread { public: static void* worker(void* args) { //~ thread execution. } private: //~ here some data member. }; pthread_t tid; pthread_create(&tid, NULL, &Thread::worker, NULL); |
我们又知道，静态成岩函数是不能’直接’访问类的非静态成员（包括函数），因此，上面代码中worker即使属于class Thread的类域，但却无法访问这个类的成员，这让人十分不爽。哪位大牛说过来着？任何一个复杂的计算机问题，都可以通过中间层来解决。这里也可以建立一个中间层：使用静态成员函数创建线程，给该函数传递某个对象的地址作为参数，在该静态函数中就可以通过所传递对象的使用它的任何成员了。
C/C++提供了函数的可变参数(variadic)机制，大部分人写的第一个C程序恐怕就是Hello World吧，使用的应该也是printf(“Hello, World\n”)。printf就是一个使用可变参数的典型，它的原型声明为，
int printf(const char *fmt, ...); |
其中返回值为实际输出字符个数，fmt为格式控制字符串，而”…”便声明了一个可变参数，你可以根据传递0个或多个参数给printf。printf内部会根据格式控制串中的格式指定符号（d, f, p等等）来逐个解析通过可变参数传进的实参变量。
为解析可变参数，C语言提供了一个va_list类型和四个宏，分别是va_start, va_arg, va_end, 和va_copy，这些宏声明在stdarg.h中。
关于虚函数，需要知道：
reserve内部是怎么实现的呢？当然是new了。那么在reserve操作，也就是new之后，我们程序是否立即就占用了这些内存呢？这就要看我们这里说的“内存”是什么样的内存了。什么意思呢？我们知道，现代操作系统都采用了虚拟内存的机制，内存占用也就有了虚拟内存（virtual memory）和物理内存（physical memory）之分了。
我们又知道，Unix/Linux进程的虚拟地址空间被按用途被划分成了内核空间和用户空间。内核空间供操作系统的内核使用，用户空间供用户程序支配。其中用户空间又被划分为若干段，主要包括：代码段（.text），用来存放/映射用户程序的代码；数据段（.data），存放初始化的全局数据或静态数据，这部分在文件系统中也占据磁盘空间；.bss段（一直没找到一个亲切的翻译），存放为初始化的全局或静态数据，在程序加载时分配空间和初始化，这部分空间不占用磁盘空间（当然在可执行文件中要保留其大小）；堆栈段，用来保存程序执行时的上下文（局部变量、函数参数和返回地址等），在进程建立时由操作系统分配，空间较小且在运行时不可动态调整，增长方向因机器架构而异，IA上自高地址向下增长，堆栈不占用磁盘空间；堆，供用户在运行时动态地申请和使用，空间较大，未被申请的堆空间不可使用，也不会被映射到物理空间，堆随着用户程序申请向上增长，堆不占用磁盘空间。
关于C++ STL容器的默认内存管理，需参考allocator。
关于deque的内存模型及其clear操作，我不甚了了，请参考您使用的标准库的代码。
若想深入了解STL的实现，侯捷大叔的《STL源码剖析》是不错的入门资料，希望能够拜读。
C++标准中并未对STL的实现细节做过多规定，因此不同实现的细节和表现可能不同。
C++很复杂，但也并非无底黑洞。学好C++很难，但这种学习过程也会使你收获颇丰。
学习任何一种技术，都需要热情、激情和足够的耐心。
做好一件事，需要激情，同时激情常常来源于做好一件事情的满足感。
满足感会增强人分享的欲望，分享的欲望也常常会使人具有亲和力和感染力，使人觉得你有激情，反过来更有利于人做好一件事。
blabla, over~
头文件中通常包含有：函数原型（声明）、宏定义、内联函数定义。
头文件使用#include宏命令引入。有两种形式：#inlcude <header.h>和#include “header.h”. 两种形式的区别在于预处理器（preprocessor）查找头文件的方式的不同：对于前者，预处理器仅在系统预定义的标准路径中查找（标准查找路径由环境变量指明），比如/usr/include, /usr/local/include；对于后者，预处理器首先查找（源文件所在的）当前目录，若未找到，则到标准路径查找。另外，查找路径还可以通过编译器选项（-I for gcc）指定。通常，对于C/C++标准库和其他系统范围的程序库，使用<>形式，对于程序本身定义的头文件，采用”"形式。
在很多C/C++头文件中，你可能会经常看到使用extern “C”{}包含起来的代码。这种语法的存在是为了使C和C++代码能够兼容。兼容？C++对C本来不就是兼容的吗？确实，在语法层面，C++支持几乎所有C语法。但这里的兼容是目标文件或者库级别的兼容，包括两种情况下的兼容。一种是，在C++代码中调用已经存在的C代码写成的库；另一种是，使用C编写代码，而希望这些代码能够使C++可以调用。
若想继续讨论extern “C”，就不得不提name mangling。
我们知道，相比C，C++支持函数重载，支持命名空间，支持类以及成员函数。函数重载允许我们声明名字相同参数不同的函数，命名空间（namespace）和类为名字（或者说符号）划分了不同的域使得我们可以在不同域中使用完全相同的名字。而为了实现这种特性，C++就使用了name mangling。即是说，C++编译器在编译C++文件时，把每一个函数名“打乱”成与函数所在域、参数类型、调用约定相关的另外一个名字（因为汇编级别的代码中，所有符号都在同一个域）。由于C中并不存在这些特性，所以通常C编译器并不对符号进行mangling。
在形如struct structName varName;的语句中，struct是必须的吗？这是一个显而易见的语法问题，但却容易被忽略，尤其容易被C+C++的同志们忽略。
在标准C中，struct关键字是必须的：
1 2 3 4 5 6 7 8 9 10 | struct structName { int n; }; //~ typedef struct structName structName; int main() { struct structName n; return 0; } |
若没有前置的struct关键字，上面的代码就不能通过编译。我的gcc会提示”structName” undeclared, parse error before ‘n’的错误。为了方便，通常会使用typedef struct structName structName;语句来为struct structName定义类型别名。
但是，在C++中，一般情况下，struct/class关键字就不是必须的。但是，在有些情况下struct/class关键字又是必须的，因为这时的名字structName有歧义性。这是因为，C/C++语言允许用户自定义类型和函数同名。
有码有真相，各位看官您上眼：
1 2 3 4 5 6 | int main() { bar(++foo(372)); //~ 此行报错 bar(++foo(wrap_int(372))); //~ 无错 return 0; } |
第一个bar调用中foo返回int型临时对象，想要把这个int临时对象++后传给bar，未遂。第二个bar调用中，foo返回一个包装过的int, 即wrap_int，对这个临时对象进行++(重载)，得逞。结论：C++中，基本类型（内置类型）的临时对象不可以作为左值（l-value），即不可以修改；用户自定义类型的临时对象可以作为左值。
提到C++ STL，首先被人想到的是它的三大组件：Containers, Iterators, Algorithms，即容器，迭代器和算法。容器为用户提供了常用的数据结构，算法大多是独立于容器的常用的基本算法，迭代器是由容器提供的一种接口，算法通过迭代器来操控容器。接下来要介绍的是另外的一种组件，函数对象（Function Object，JJHou译作Functor仿函数）。
顾名思义，函数对象首先是一个对象，即某个类的实例。其次，函数对象的行为和函数一致，即是说可以像调用函数一样来使用函数对象，如参数传递、返回值等。这种行为是通过重载类的()操作符来实现的，举例说明之，
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | class Print { public: void operator()(int n) { std::cout<<n<<std::endl; return ; } }; int main(int argc, char **argv) { Print print; print(372); print.operator()(372); //~ 显式调用 return 0; } |