亚洲高清不卡在线观看,国产精品欧美日韩,欧美精品一区二区三区蜜桃

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

该文章包�?个部分�?img src ="http://m.shnenglu.com/zerolee/aggbug/20876.html" width = "1" height = "1" />

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

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

�ȝ��Q?br />    有四�U�情况，�?x��)导致“编译器必须为未声明构造函数的classes合成一个默认构造函数”。C++ 标准把那些合成物�U�Cؓ(f��)隐含的有用默认构造函数。被合成出来的构造函数只能满��编译器(非程�?的需要。它之所以能够完成�Q务，是借着“调用成员对象或基类的默认构造函数”或是“�ؓ(f��)每一个对象初始化其虚函数机制或虚基类机制”而完成的。至于没有存在那四种情况而又没有声明构造函数的�c�，我们说它们拥有的是隐含的无用默认构造函敎ͼ�实际上它们�ƈ不被合成出来�?br />    在合成的默认构造函��C��Q�只有基�c�d��对象和成员对象会(x��)被初始化。所有其它的非静态数据成员，如整数、整数指针、整数数�l�等�{�都不会(x��)被初始化。这些初始化操作对程序而言有需要，但对�~�译器而言则没必要。如果程序需要一个“把某指针设�?”的默认构造函敎ͼ�那么提供它的人应该是�E�序员�?br />
    C++新手一般有两个常见的误解：(x��)
1�Q��Q何类如果没有定义默认构造函敎ͼ��~�译器就�?x��)合成出它来�?br />2�Q�编译器合成出来的默认构造函��C��(x��)明确讑֮�“类中每一个数据成员的默认值”�?br />
正如你所见，上述两个没有一个是真的�Q?br />-------------------------------------------------------------------------------------------
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 发表评论

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

输出字符'A'/'a'的代码段�Q?br />

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是字�W?A'�?6�q�制表示方式�Q�它�?0�q�制数是65�Q�\x41是字�W?A'的�{义字�W�。�?x0A跟字�W?A'没有丝毫关系�Q�顶多就�?x0A借用了字�W?A'而已。故如果惛_��屏幕上输出字�W?A'可将其�{义字�W�直接插入输出流中，或者将0x41转化为字�W�类型，然后插入�Q�不得��?x41直接插入�Q�因�?x41本��n是int�c�d��?0�q�制�?5。同时也不可以将'0x41'直接插入输出��，因�ؓ(f��)'0x41'是int�c�d��的数�?br /> 可以��试使用控制�W�std::hex来插入字�W?a'到输出流�?br />

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

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

资料整理于《大规模C++�E�序设计》 �?br /> 在头文�g的文件作用域中声明的名称�Q�可能潜在地与整个系�l�中��M��一个文件的文�g作用域名�U�冲�H�。即使在一�?cpp文�g的文件作用域中声明的带有内部�q�接的名�U�C��不能保证一定不�?h文�g的作用域名称冲突�?br /> 主要设计规则�Q?font color="#ff0000">只有�c�R��结构、联合和自由�q�算�W�函数应该在.h文�g作用域内声明�Q�只有类、结构、联合和内联函数成员或（内联�Q�自��p��符应该�?h文�g的作用域内定义�?br /> 以下代码�D�阐�q�C��上述设计规则�?/font>

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 发表评论

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

Item1: vector的��?/font>
JG问题�Q?br />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 }

对于以上两个问题�Q�可能存在如下的��Q?br />1) JG问题中B与A的区�?br /> 如果V非空�Q�则A与B无�Q何区别，如果V为空�Q�则B行将一定会(x��)抛出一个std::out_of_range异常�Q�至于A的行为，标准�q�未加�Q何说明�?br /> 原因在于�Q�at()成员函数�?x��)对其进行越界检查，而operator[]操作�W�则不会(x��)�Q�秉承于数组[]下标�q�算�W�也不会(x��)��(g��)查越界一栗��?br />
2) GURU问题
代码�Q?br />

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

1> 断言可能�?x��)失败。reserve()函数的调用会(x��)保证v的容量至��ؓ(f��)2�Q�也可能大于2�Q�而且定w��是呈指数速度上升的。应该改为assert(v.capacity() >= 2);
2> 但是改进后的断言昄��有点多余。因为标准已保证断言的内容，写上只会(x��)带来不必要的混�ؕ�Q�除非不�怿�标准�?br />代码�Q?br />

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

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

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

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

// zero

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

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

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

增添于网上的一些书单：(x��)
C++/OPP/OOD�p�d��:
层��一�Q�语�?语意(C++)
[Lippman2000] Essential C++
Essential C++,by Stanley B. Lippman Addison Wesley Longman 2000,276 pages
Essential C++ 中文�?�Q�侯俊杰译，282��?br />Desc: �q�本书概要性的介绍了C++核心的东西，但讲得较��显�Q�适合刚入门的人阅诅R�?br />

[Andrew Koeing & Barbara MOO] Accelerated C++
Accelerated c++, Andrew Koeing & Barbara MOO, Addison Wesley, 2000
Desc: �q�本书相当不错，讲解的C++�~�程的实践东�ѝ��也相当适合预�m固C++语法知识的�h阅读�?br />
[Eckel2000] Thinking in C++
Thinking in C++ 2/e Bruce Eckel 2000 1470 pages Prentice Hall
C++ �~�程思想�Q�刘宗田�{?译，420��?

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

[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

层��二：(x��)专家�l�验(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��?br />Effective C++, Third Edition, by Scott Meyers, Addison Wesley Longman.

[Sutter99] Exceptional C++
Exceptional C++�Q�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.

层��三：(x��)底层机制(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++物�g模型�Q�侯俊杰 �?

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

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

Genericity/STL�p�d��(与层�U�二同步�Q?
�W�一个境界是使用STL:
[Josuttis99]:The C++ Standard Library �Q�A Tutorial and Reference,by Nicolai M.Josuttis,
Addison Wesley 1999.799pages

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

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

其他书目�Q?br />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 源码剖析�Q�侯�?br />12. C++ Coding Standards 101 Rules Guidelines, Andrie Alexandrescu & Herb Sutter, Addison Wesley, 2005

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