C++博客-一步一个脚印，走在自己前面！-随笔分类-C++ Performance

编译期的依赖性系列

仄洛 — Thu, 29 Mar 2007 07:02:00 GMT

该文章包括3个部分。

仄洛 2007-03-29 15:02 发表评论

编译器何时为你产生默认构造函数

仄洛 — Tue, 27 Mar 2007 02:21:00 GMT

总结：
    有四种情况，会导致“编译器必须为未声明构造函数的classes合成一个默认构造函数”。C++ 标准把那些合成物称为隐含的有用默认构造函数。被合成出来的构造函数只能满足编译器(非程序)的需要。它之所以能够完成任务，是借着“调用成员对象或基类的默认构造函数”或是“为每一个对象初始化其虚函数机制或虚基类机制”而完成的。至于没有存在那四种情况而又没有声明构造函数的类，我们说它们拥有的是隐含的无用默认构造函数，实际上它们并不被合成出来。
    在合成的默认构造函数中，只有基类子对象和成员对象会被初始化。所有其它的非静态数据成员，如整数、整数指针、整数数组等等都不会被初始化。这些初始化操作对程序而言有需要，但对编译器而言则没必要。如果程序需要一个“把某指针设为0”的默认构造函数，那么提供它的人应该是程序员。

    C++新手一般有两个常见的误解：
1）任何类如果没有定义默认构造函数，编译器就会合成出它来。
2）编译器合成出来的默认构造函数会明确设定“类中每一个数据成员的默认值”。

正如你所见，上述两个没有一个是真的！
-------------------------------------------------------------------------------------------
Summary:
   There are four characteristics of a class under which the compiler needs to synthesize a default constructor for classes that declare no constructor at all. The Standard refers to these as implicit, nontrivial default constructors. The synthesized constructor fulfills only an implementation need. It does this by invoking member object or base class default constructors or initializing the virtual function or virtual base class mechanism for each object. Classes that do not exhibit these characteristics and that declare no constructor at all are said to have implicit, trivial default constructors. In practice, these trivial default constructors are not synthesized.

Within the synthesized default constructor, only the base class subobjects and member class objects are initialized. All other nonstatic data members, such as integers, pointers to integers, arrays of integers, and so on, are not initialized. These initializations are needs of the program, not of the implementation. If there is a program need for a default constructor, such as initializing a pointer to 0, it is the programmer's responsibility to provide it in the course of the class implementation.

Programmers new to C++ often have two common misunderstandings:

1) That a default constructor is synthesized for every class that does not define one
2) That the compiler-synthesized default constructor provides explicit default initializers
for each data member declared within the class

As you have seen, neither of these is true.

--------------------------------------------------------------------------------------------

仄洛 2007-03-27 10:21 发表评论

输出字符'A'/'a'的解析

仄洛 — Mon, 15 Jan 2007 02:59:00 GMT

输出字符'A'/'a'的代码段：

1     // Test1: Directly insert 0x0A and 0x41 to ostream
2    cout << 0x0A;    // print type int 10
3
4    cout << ' ';
5
6    cout << 0x41;    // print type int 65, which is decimal number of 'A'.
7    cout << ' ';
8
9    // Test2: Directly insert '\x41' to ostream
10    cout << '\x41';    // '\x41' is transformed char, which means type char 'A'.
11                       // So, it prints type char 'A' on screen.
12    cout << ' ';
13
14    // Test3: First assign 0x41 to char variable, then output it.
15    char char_out = 0x41;    // char_out is equal 'A' which is type int 65.
16    cout << char_out;        // it prints type char 'A' on screen.
17
18    cout << ' ';
19    // Test4: First cast 0x0A to char, then output it.
20    cout << static_cast<char>(0x41); // it prints type char 'A' on screen.
21
22    cout << ' ';

23    // Test5: Directly insert hexdecimal type number of 'A'
24     cout << std::hex /*<< std::showbase*/ << 0x41; // it prints string literal "41"
25    cout << ' ' << std::hex << 0x0A; // it prints type char 'a' on screen.
26    int int_out = '0x41';
27    cout << int_out; // it prints type int 8342**
28
29    cout << endl;

0x41是字符'A'的16进制表示方式，它的10进制数是65，\x41是字符'A'的转义字符。而0x0A跟字符'A'没有丝毫关系，顶多就是0x0A借用了字符'A'而已。故如果想在屏幕上输出字符'A'可将其转义字符直接插入输出流中，或者将0x41转化为字符类型，然后插入，不得使用0x41直接插入，因为0x41本身是int类型的10进制数65。同时也不可以将'0x41'直接插入输出流，因为'0x41'是int类型的数。
可以尝试使用控制符std::hex来插入字符'a'到输出流。

仄洛 2007-01-15 10:59 发表评论

头文件中的名称

仄洛 — Sun, 07 Jan 2007 07:00:00 GMT

资料整理于《大规模C++程序设计》
   在头文件的文件作用域中声明的名称，可能潜在地与整个系统中任何一个文件的文件作用域名称冲突。即使在一个.cpp文件的文件作用域中声明的带有内部连接的名称也不能保证一定不与.h文件的作用域名称冲突。
   主要设计规则：只有类、结构、联合和自由运算符函数应该在.h文件作用域内声明；只有类、结构、联合和内联函数成员或（内联）自由运算符应该在.h文件的作用域内定义。
   以下代码段阐述了上述设计规则。

1 // Driver.h                      // fine:comment
2 #ifndef INCLUDED_DRIVER          // fine:internal include guard
3 #define INCLUDED_DIRVER
4
5 #ifndef INCLUDED_NIFTY           // fine:redundant include guard
6 #include " nifty.h "
7 #endif
8
9 #define PI 3.141592              // Avoid:macro constant
10 #define MIN(X) ((X)<(Y)?(X):(Y)) // Avoid:macro constant
11
12 class ostream;                // fine: class dec.
13 struct DriverInit;            // fine: class dec.
14 union Uaw;                    // fine: class dec.
15
16 extern int globalVariable; // Avoid:external data dec.
17 static int fileScopeVariable; // Avoid:internal data def.
18 const int BUFFER_SIZE = 256 ; // Avoid:const data def.
19 enum Boolean { zero, one } ;   // Avoid:enumeration at file scope
20 typedef long BigInt;          // typedef at file scope
21
22 class Driver {
23     enum Color { RED, GREEN } ; // fine:enumeration in class scope
24    typedef int (Dirver:: * PMF)(); // fine: typedef in class scope
25     static int s_count;       // fine:static member dec.
26     int d_size;     // fine: member data def.
27
28 private :
29     struct Pnt {
30        short int d_x, d_y;
31       Pnt( int x, int y)
32        : d_x(x), d_y(y) { }
33    } ;               // fine: private struct def.
34    friend DirverInit;   // fine: friend dec.
35
36 public :
37     int static round( double d);   // fine:static member function dec.
38     void setSize( int size); // fine: member function dec.
39     int cmp( const Driver & ) const ; // fine: const member function dec.
40 } ;                // fine: class def.
41
42 static class DriverInit {
43    //
44 } DriverInit;    // Special class
45
46 int min( int x, int y);   // Avoid: free function dec.
47
48 inline int max( int x, int y)
49 {
50     return x > y ? x : y;
51    }     // Avoid free inline function def.
52
53 inline void Driver::setSize( int size)
54 {
55    d_size = size;
56 }      // fine: inline member function def.
57
58 ostream & operator << (ostream & o, const Dirver & d);   // fine: free operator function def.
59
60 inline int operator == ( const Driver & lhs, const Dirver & rhs)
61 {
62     return compare(lhs, rhs) == 0 ;
63 }      // fine: free inline operator func. def.
64
65 inline int Driver::round( double d)
66 {
67    retrun d < 0 ? - int ( 0.5 - d) : int ( 0.5 + d);
68 }      // fine: inline static member func. def.
69
70 #endif
71
72

仄洛 2007-01-07 15:00 发表评论

The Return Value Optimization[2]

仄洛 — Mon, 13 Nov 2006 11:36:00 GMT

------->
Without any optimization, the compile-generated(pseduo) code for Complex_Add() is

1 void Complex_Add( const Complex & __tempResult, const Complex & c1, const Complex & c2)
2 {
3     struct Complex retVal;
4    retVal.Complex::Complex(); // Constructor retval
5    retVal.real = a.real + b.real;
6    retVal.imag = a.imag + b.imag;
7    __tempResult.Complex::Complex(retVal); // copy-constructor
8   retVal.Complex:: ~ Complex(); // destroy retVal
9    return ;
10 }

The compiler can optimize Complex_Add() by eliminating the local object retVal and replacing it with __tempResult. This is the Return Value Optimization:

1 void Complex_Add( const Complex & __tempResult, const Complex & c1, const Complex & c2)
2 {
3    __tempResult.Complex::Complex();   // construcotr __tempResult
4    __tempResult.real = a.real + b.real;
5    __tempResult.imag = a.imag + b.imag;
6     return ;
7 }

The RVO eliminated the local retVal object and therefore saved us a constructor as well as a destructor computation.
To get a numerical feel for all this efficiency discussion, we measured the impact of RVO on execution speed. We coded two versions of operator +(), one of which was optimized and the other not. The measured code consisted of a million loop iterations:

1 int main()
2 {
3    Complex a( 1 , 0 );
4    Complex b( 2 , 0 );
5    Complex c;
6     // begin timing here
7     for ( int i = 1000000 ; i > 0 ; -- i) {
8       c = a + b;
9    }
10     // stoping timing here
11 }

The second version, without RVO, executed in 1.89 seconds. The first version, with RVO applied was much faster --1.30 seconds.

Compiler optimizations, naturally, must preserve the correctness of the original computation. In the case of the RVO, this is not always easy. Since the RVO is not mandatory, the compiler will not perform it on comlicated functions. For example, if the function has multiple return statements returning objects of different names, RVO will not be applied. You must return the same named object to have a chance at the RVO.
One compiler we tested refused to apply the RVO to this particular version of operator +:

1Complex operator +(const Complex& a, const Complex& b)
2{
3   // operator + version 1
4   Complex retVal;
5   retVal.real = a.real + b.real;
6   retVal.imag = a.imag + b.imag;
7   return retVal;
8}

It did, however, apply the RVO to this version:

1Complex operator +(const Complex& a, const Complex& b)
2{
3   // operator + version 2
4   double r = a.real + b.real;
5   double i = a.imag + b.imag;
6   return Complex(r, i);
7}
8

We speculated that the difference may lie in the fact that Version 1 used a named variable(retVal) as a return value whereas Version 2 used an unnamed variable. Version 2 used a constructor call in the return statement but never named it. It may be the case that this particular compiler implementation chose to avoid optimizing away named variables.
Our speculation was boosted by some additional evidence. We tested two more versions of operator +:

1Complex operator +(const Complex& a, const Complex& b)
2{
3   // operator + version 3
4   Complex retVal(a.real + b.real, a.imag + b.imag);
5   return retVal;
6}
7and
8Complex operator +(const Complex& a, const Complex& b)
9{
10   // operator + version 4
11   return Complex(a.real + b.real, a.imag + b.imag);
12}

As speculated, the RVO was applied to Version 4 but not to Version 3.
In addition, you must also define a copy constructor to "Turn on" the Return Value Optimization. If the class involved does not have a copy constructor defined, the RVO is quietly turned off.

Key Points:
[1] If you must return an object by value, the Return Value Optimization will help performance by eliminating the nedd for creation and destruction of a local object.

[2] The application of the RVO is up to the direction of the compiler implementation. You need to consult your compile documentation or experiment to find if and when RVO is applied.

[3] You will have a better shot at RVO by deploying the computational constructor.

仄洛 2006-11-13 19:36 发表评论

The Return Value Optimization[1]

仄洛 — Mon, 13 Nov 2006 11:01:00 GMT

Resource from the book:
Dov Bulka & David Mayhew

Anytime you can skip the creation and destruction of an object, you are looking at a performance gain. We will discuss an optimization often performed by compilers to speed up your source code by transforming it and eliminating object creation. This optimization is referred to as the Return Value Optimization(RVO). Prior to delving into the RVO we need to understand how return-by-value works. We will walk through it with a simple example.

The Mechanics of Return-by-Value
The Complex class implements a representation for complex numbers:

1 class Complex
2 {
3     // Complex addition operator
4     friend Complex operator + ( const Complex & , const Complex & );
5 public :
6     // default constructor
7     // Value defaults to 0 unless otherwise specified
8     Complex( double r = 0.0 , double i = 0.0 ):real(r), imag(i) { }
9
10     // copy constructor
11     Complex( const Complex & c):real(c.real), imag(c.imag) { }
12
13     // Assignment operator
14     Complex & operator = ( const Complex & c);
15
16     ~ Complex() { }
17 private :
18     double real;
19 } ;

The addition operator returns a Complex object by value, as in:

1 Complex operator + ( const Complex & a, const Complex & b)
2 {
3     Complex retVal;
4     retVal.real = a.real + b.real;
5     retVal.imag = a.imag + b.imag;
6      return retVal;
7 }

Suppose c1, c2, and c3 are Complex and we excute
c3 = c1 + c2;
How do we get the value of c1 + c2 into c3? One popular technique used by compilers is to create a temporary __result object and pass it into Complex::operator +() as a third argument. It is passed by referece. So the compiler rewrites

1 Complex & Complex:: operator + ( const Complex & c1, const Complex & c2)
2 {
3
4 }

into a slightly different function:

1 void Complex_Add( const Complex & __result, const Complex & c1, const Complex & c2)
2 {
3
4 }

Now the original source statement
c3 = c1 + c2;
is transformed into(pseudocode):

1 struct Complex __tempResult; // Storage. No constructor here.
2 Complex_Add(__tempResult, c1, c2); // All argument passed by reference.
3 c3 = __tempResult; // Feed result back into left-hand-side.

This return-by-value implementation opens up an optimization opportunity by eliminating the local object RetVal(inside operator +()) and computing the return value directly into the __tempResult temporary object. This is the Return Value Optimization.

仄洛 2006-11-13 19:01 发表评论

Template and Inheritance

仄洛 — Mon, 13 Nov 2006 05:37:00 GMT

As Meyers noted in Item 24 of Effective C++,the inability to inline a virtual function is its biggest performace penalty.
Virtual functions seems to inflict a performace cost in several ways:
[1] The vptr must be initialized in the constructor.
[2] A virtual function is invoked via pointer indirection. We must fetch the pointer to the function table and then access the correct function offset.
[3] Inlining is a compile-time decision. The compiler cannot inline virtual functions whose resolution takes place at run-time.
The true cost of virtual functions then boils down to the third item only.

-------------------------------------------------------------------------------------------
Virtual function calls that can be resolved only at rum-time will inhibit inling. At times, that may pose a performace problem that we must solve. Dynamic binding of a function call is a consequence of inheritance. One way to eliminate dyanamic binding is to replace inheritance with a template-based design. Templates are more performance-friendly in the sense that they push the resolution step from run-time to compile-time. Compile-time, as far as we are concerned, is free.

The desing space for inheritance and templates has some overlap. We will discuss one such example.

Suppose you wanted to develop a thread-safe string class that may be manipulated safely by concurrent threads in a Win32 environment. In that environment you have a choice of multiple synchronization schemes such ascriticalsection, mutex, and semanphores, just to name a few. You would like your thread-safe string to offer the flexibility to use any of those schemes, and at different times you may have a reason to prefer one scheme over another. Inheritance would be a reasonable choice to capture the commonality among synchronization mechanisms.

The Locker abstract base class will declare the common interface:

1 class Locker
2 {
3 public :
4     Locker() { }
5      virtual ~ Locker() { }
6      virtual void lock () = 0 ;
7      virtual void unlock() = 0 ;
8 } ;
9
10 class CriticalSectionLock : public Locker
11 {
12
13 } ;
14 class MutexLock : public Locker
15 {
16
17 } ;

Because you prefer not to re-invent the wheel, you made the choice to derive the thread-safe string from the existing standard string. The remaining design choices are:

[1] Hard coding. You could derive three distinct classes from string::CriticalSectionString, MutexString, and SemaphoreString, each class implementing its implied synchronization mechanism.
[2] Inheritance. You could derive a single ThreadSafeString class that contains a pointer to a Locker object. Use polynorphism to select the particular synchronization mechanism at run-time.
[3] Templates. Create a template-based string class parameterized by the Locker type.
////////////////////////////////////////////////////////////////////////////////////////////
Here we only talk about the Template implementation.

The templates-based design combines the best of both worlds-reuse and efficiency. The ThreadSafeString is implemented as a template parameterized by the Locker template argument:

1template <class LOCKER>
2class ThreadSafeString : public string
3{
4public:
5   ThreadSafeString(const char* s)
6   : string(s) { }
7
8   int length();
9private:
10   LOCKER lock;
11};
12

The length method implementation is similar to the previous ones:

1template <class LOCKER>
2inline
3int ThreadSafeString<LOCKER> :: length()
4{
5  lock.lock();
6  int len = string::length();
7  lock.unlock();
8
9  return len;
10}

If you want critical section protection, you will instantiate the template with a CriticalSectionLock:
{
   ThreadSafeString csString = "Hello";
   ...
}
or you may go with a mutex:
{
   ThreadSafeString mtxString = "Hello";
   ...
}

This design also provides a relief from the virtual function calls to lock() and unlock(). The declaration of a ThreadSafeString selects a particular type of synchronization upon template instantiation time. Just like hard coding, this enables the compiler to resolve the virtual calls and inline them.

As you can see, templates can make a positive performace contribution by pushing computations out of the excution-time and into compile-time, enabling inling in the process.

仄洛 2006-11-13 13:37 发表评论

关于vector的使用

仄洛 — Sat, 14 Oct 2006 07:05:00 GMT

Item1: vector的使用
JG问题：
void f(vector& v) {
v[0] = 1; // A
v[1] = 2; // B
}
GURU问题:

1 vector < int > v;
2 v.reserve( 2 );
3 assert(v.capacity() == 2 );
4 v[ 0 ] = 1 ;
5 v[ 1 ] = 2 ;
6 for (vector < int > ::iterator i = v.begin();
7        i < v.end(); i ++ ) {
8     cout << * i << endl;
9 }
10 cout << v[ 0 ];
11 v.reserve( 100 );
12 assert(v.capacity() == 100 );
13 cout << v[ 0 ];
14 v[ 2 ] =    3 ;
15 v[ 3 ] = 4 ;
16 // ...
17 v[ 99 ] = 100 ;
18 for (vector < int > ::iterator i = v.begin();
19        i < v.end(); i ++ ) {
20     cout << * i << endl;
21 }

对于以上两个问题，可能存在如下的建议：
1) JG问题中B与A的区别
如果V非空，则A与B无任何区别，如果V为空，则B行将一定会抛出一个std::out_of_range异常，至于A的行为，标准并未加任何说明。
原因在于：at()成员函数会对其进行越界检查，而operator[]操作符则不会，秉承于数组[]下标运算符也不会检查越界一样。

2) GURU问题
代码：

1 vector < int > v;
2 v.reserve( 2 );
3 assert(v.capacity() == 2 );
4

1> 断言可能会失败。reserve()函数的调用会保证v的容量至少为2，也可能大于2，而且容量是呈指数速度上升的。应该改为assert(v.capacity() >= 2);
2> 但是改进后的断言显的有点多余。因为标准已保证断言的内容，写上只会带来不必要的混乱，除非不相信标准。
代码：

1 v[ 0 ] = 1 ;
2 v[ 1 ] = 2 ;
3

size ——>resize, capacity ——> reserve
1> size告诉你容器中目前实际有多少元素，而对应的resize会在容器的尾部添加或删除一些元素，来调整容器当中的实际内容，使容器达到指定大小。对list、deque和vector适用，其他容器则不适用；
2> capacity则告诉你最少添加多少元素才会导致容器重分配内存。而reserve在必要时总是使容器的内存缓冲区扩至一个更大的容量。仅对vector有用。
3> 但我们实际上并未向v中添加任何元素，v仍然为空！我们只能使用at()或[]去改变那些确实存在于容器中的元素，与容器大小息息相关的。
因此v[0] = 1; v[1] = 2;在某些情况下会“顺利”执行，建议最好不要如此使用，可以使用resize()函数来替代reserve()函数。

代码：

1 for (vector < int > ::iterator i = v.begin();
2 i < v.end(); i ++ ) {
3 cout << * i << endl;
4 }
5

以上代码有诸如以下的建议：
1> 尽量使用const.未修改v中的内容，可使用const_iterator;
2> 尽量使用!=而不用<来比较迭代器。 != 对任何迭代器都有效，而< 只对随机访问迭代器有效。list不支持<;
3> 尽量使用++前缀，而非后缀。可以从++前后缀的实现代码中得知，除非一些特殊场合；
4> 避免无谓的重复求值。v.end()函数在重复求值，而整个循环期间都未改变。除非end()被编译器进行内联，无调用开销，最好是将其提到循环外面；
5> 尽量使用'\n'而非endl。原因在于endl会迫使输出流刷新其内部缓冲区，可以在整个循环之后写一个刷新语句。
6> 尽量使用标准库中算法. 如copy()、for_each()。例如这里就可以这样写：
copy(v.begin(), v.end(), ostream_iterator(cout, '\n'));
这样一来也避免了1> ~ 5的麻烦。

// zero

仄洛 2006-10-14 15:05 发表评论

修炼成C++高手必看的C++书单

仄洛 — Tue, 12 Sep 2006 05:11:00 GMT

增添于网上的一些书单：
C++/OPP/OOD系列:
层级一：语法/语意(C++)
[Lippman2000] Essential C++
Essential C++,by Stanley B. Lippman Addison Wesley Longman 2000,276 pages
Essential C++ 中文版，侯俊杰译，282页
Desc: 这本书概要性的介绍了C++核心的东西，但讲得较浅显，适合刚入门的人阅读。

[Andrew Koeing & Barbara MOO] Accelerated C++
Accelerated c++, Andrew Koeing & Barbara MOO, Addison Wesley, 2000
Desc: 这本书相当不错，讲解的C++编程的实践东西。也相当适合预巩固C++语法知识的人阅读。

[Eckel2000] Thinking in C++
Thinking in C++ 2/e Bruce Eckel 2000 1470 pages Prentice Hall
C++ 编程思想，刘宗田等译，420页

[Lippman98] C++Primer
C++ Primer,3rd Editoin,by Stanley Lippman and Josee Lajoie
Addison Wesley Longman,1998 1237 pages
C++ Primer 中文版，侯俊杰译，1999，1237页

[Struostrup2000] The C++ Programming Language
The C++ Programming Language,Special Editoin,by Bjarne Stroustrup
Addison Wesley Longman,2000,1017 pages

[ANSI C++] C++规格书 1998.9.1 PDF格式
ANSI C++ 1996 Draft

层级二：专家经验(C++/OOP)
[Meyers96] More Effective C++
More Effective C++, by Scott Meyers,Addison Wesley,1996,318pages
More Effective C++中文版，侯俊杰，培生 2000. 318页

[Meyers98] Effective C++
Effective C++, Second Edition,by Scott Meyers,Addison Wesley Longman,1998.256pages
Effective C++ 2/e 中文版,侯俊杰,培生 2000.256页
Effective C++, Third Edition, by Scott Meyers, Addison Wesley Longman.

[Sutter99] Exceptional C++
Exceptional C++，by Herb Sutter,Addison Wesley Longman,2000.208pages
Exceptional C++中文版，侯俊杰,培生 2000.248页

[Sutter2001]More Exceptional C++
More Exceptional C++ by Herb Sutter, Addison Wesley Longman, 2001.

[Sutter2004]Exception C++ Style
Exception C++ Style by Herb Sutter, Addison Wesley Longman, 2004.

层级三：底层机制(C++ Object Model)
[Ellis90] The Annotated C++ Reference Manual
The Annotated C++ Reference Manual,by Margaret A.Ellis and Bjarne Stroustrup
Addison Wesley Longman,1990,447 pages.

[Lippman96] Inside the C++ Object Model
Inside the C++ Object Model,by Stanley Lippman,Addison Wesley Longman,1996,280pages
深度探索C++物件模型，侯俊杰译

层级四：设计观念的复用(C++/Patterns)
[Gamma95] Design Patterns：Elements of Reusable Object Oriented Software,
by Erich Gamma,Richard Helm,Ralph Johnson,and John Vlissides,Addison Wesley,1995.395pages
设计模式,李英军等译,机械工业出版社,2000.254页

[Alex2001]Modern C++ Design: Generic Programming and Design Patterns Applied
by Andrei Alexandrescu,Addison-Wesley,2001,352Paper

Genericity/STL系列(与层级二同步）:
第一个境界是使用STL:
[Josuttis99]:The C++ Standard Library －A Tutorial and Reference,by Nicolai M.Josuttis,
Addison Wesley 1999.799pages

第二个境界是了解泛型技术的内涵与STL的学理:
[Austern98]:Generic Programming and the STL -Using and Extending the C++ Standard
Template library,by Matthew H.Austern,Addison Wesley 1998.548page

第三个境界是扩充STL:
[Stepanov2001]:C++ Standard Template Library by P.J.Plauger,Alexander A.Stepanov,
Meng Lee,David R.Musser,Prentice Hall 2001

其他书目：
1. Large-scale C++ software Design, John Lako, Addison Wesley, 1996
2. Effective STL, Scott Meyers, Addison Wesley, 1995
3. C++ FAQs, 2nd, Marshall Cline, Greg Lomow, Mike Girou, Addison Wesley, 1998
4. C++ Gotchas, Stephen Dewhurst, Addison Wesley, 2002
5. C++ templates, the complete Guide, Daveed Vandevoorde & Nicolar M.Josuttis, Addison Wesley, 2002
6. Standard C++ iostreams and Locals, Angelika Langer & Klaus Kreft, Addison Wesley, 2000
7. Design & Evolution of C++, BS, Addison Wesley, 1994
8. Modern C++ Design, Andrie Alexandrescu, Addison Wesley, 2001
9. Generative Programming, Krzysztof Czarnecki & Ulrich Eisencecker, Addison Wesley, 2000
10.Pattern-oriented software architecture, Vol1:A system of patterns, Frank Buschmann, 1996
11. STL 源码剖析，侯杰
12. C++ Coding Standards 101 Rules Guidelines, Andrie Alexandrescu & Herb Sutter, Addison Wesley, 2005

仄洛 2006-09-12 13:11 发表评论