1 #pragma once
 2
 3 class component
 4 {
 5 public :
 6     component(void);
 7   virtual void printsefl() = 0    ;
 8 public :
 9     virtual ~component(void);
10 };
11
12 class concreatecom : public  component
13 {
14 public :
15     concreatecom(char *  );
16   virtual void printsefl()   ;
17   virtual ~concreatecom(void);
18 protected:
19 private :
20 char  *  _psz_text;
21 };
22
23 class decorator: public  component
24 {
25 public :
26      decorator(component & );
27   virtual void printsefl()     ;
28   virtual ~decorator();
29 protected:
30
31 private :
32    component  &  _pcomponent;
33 };
34 class  headdeco: public  decorator
35 {
36 public :
37        headdeco(component & , int );
38    virtual void printsefl()   ;
39    virtual ~headdeco();
40 protected:
41     virtual void printhead()  ;
42 private :
43 int  _i_head;
44 };
45
46 class enddeco: public  decorator
47 {
48 public :
49       enddeco(component & ,char * );
50     virtual void printsefl() ;
51     virtual  ~enddeco();
52 protected:
53       virtual void printend() ;
54 private :
55  char *  _pch_end;
56 };

 1 #include  " StdAfx.h "
 2 #include  < iostream >
 3 #include  " component.h "
 4 using namespace std;
 5
 6 component::component(void)
 7 {
 8 }
 9
10 component::~component(void)
11 {
12 }
13
14 void concreatecom::printsefl() 
15 {
16    cout << endl;
17    cout << _psz_text ;
18    cout << endl;
19 }
20  concreatecom::concreatecom(char *  psz)
21 {
22       _psz_text = psz;
23 }
24  decorator::decorator(component &  a):
25    _pcomponent(a)
26 {
27   
28 }
29 concreatecom::~concreatecom()
30 {
31
32 }
33 void decorator::printsefl()
34 {
35 _pcomponent.printsefl();
36     
37 }
38
39 decorator::~decorator()
40 {
41
42 }
43
44  headdeco::headdeco(component  &  refcom,  int  i):
45   decorator(refcom)
46  ,_i_head(i)
47 {
48
49 }
50 void headdeco::printsefl() 
51 { 
52    printhead();
53    decorator::printsefl();
54    
55 }
56 void headdeco::printhead() 
57 {
58     cout << endl;
59    cout << _i_head;
60    cout << endl;
61 }
62 headdeco::~headdeco()
63 {
64  
65 }
66
67 enddeco::enddeco(component  &  refcom,char  *  pch)
68 :decorator(refcom)
69 ,_pch_end(pch)
70 {
71    
72 }
73 void enddeco::printsefl() 
74 {
75     decorator::printsefl();
76     printend();
77 }
78 void enddeco::printend()  
79 {
80     cout << endl;
81     cout << _pch_end;
82     cout << endl;
83 }
84 enddeco::~enddeco()
85 {
86
87 }

 1 //  decorator.cpp : 定义控制台应用程序的入口点。
 2 //
 3
 4 #include  " stdafx.h "
 5 #include  < iostream >
 6 #include  " component.h "
 7 using namespace std;
 8
 9  void printmodel(component &  pcom )
10 {
11     pcom.printsefl();
12 }
13 int  _tmain( int  argc, _TCHAR *  argv[])
14 {
15      
16     printmodel(headdeco(headdeco(enddeco(concreatecom( " 正文输出中。。。。 " ), " 黄大仙 " ), 2 ), 1 ));
17     return  0 ;
18 }
19

       这个decorator 模式例子让初学者 更能加深 多态威力的体会和 decorator 模式 比子类灵活的体会
要注意的问题是：对象链总是在 concreatecomponent  对象处结束。

  ///此处是client 使用 对象的入口点，仅仅得到了 1个 decorator 的派生类对象，client 什么都不知道
printmodel(headdeco(headdeco(enddeco(concreatecom("正文输出中。。。。"),"黄大仙"),2),1));
///

     在vc2005 下通过

Elements inserted into an STL container can be of any object type that supplies a public copy constructor, a public 
                                      public 拷贝构造 ，public 析构 ,public 赋值操作符   elem& operator =( elem const &)
destructor, and a public assignment operator. The destructor may not throw an exception. Furthermore, associative 
                                                                       析构不能抛出异常
containers such as set and map must have a public comparison operator defined, which is operator< by default. Some 
                             关联容器  除此外 还应由有 比较操作符
                  operations on containers might also require a public default constructor and a public equivalence operator.




以下是  各容器 迭代器类型输出代码

 1#include <vector>
 2#include <list>
 3#include <deque>
 4#include <set>
 5#include <map>
 6using namespace std;
 7template <typename inputitrator >
 8void predict(inputitrator  a)
 9{   iterator_traits<inputitrator>::iterato_category  b;
10   
11   cout<< endl<< "  "<<typeid(b).name();
12}
13
14
15main()
16
17{
18  vector<int> a;
19  deque<int> b;
20  list<int> c;
21  set<int> d;
22  map<int> e;
23  
24   predict(a.begin());
25   predict(b.begin());
26   predict(c.begin());
27    predict(d.begin());
28     predict(e.begin());
29
30}

output iterator
   -> forward iterator
   -> bidirectional iterator
   -> random-access iterator

input iterator
   -> forward iterator
   -> bidirectional iterator
   -> random-access iterator

class B { ... };
class C : public B { ... };
class D : public C { ... };

void f(D* pd)
{
   C* pc = dynamic_cast<C*>(pd);   // ok: C is a direct base class
                                 // pc points to C subobject of pd 

   B* pb = dynamic_cast<B*>(pd);   // ok: B is an indirect base class
                                 // pb points to B subobject of pd 
   ...
}

This type of conversion is called an "upcast" because it moves a pointer up a class hierarchy, from a derived class to a class it is derived from. An upcast is an implicit conversion.

If type-id is void*, a run-time check is made to determine the actual type of expression. The result is a pointer to the complete object pointed to by expression. For example:

class A { ... };

class B { ... };

void f()
{
   A* pa = new A;
   B* pb = new B;
   void* pv = dynamic_cast<void*>(pa);
   // pv now points to an object of type A
   ...
   pv = dynamic_cast<void*>(pb);
   // pv now points to an object of type B
}

If type-id is not void*, a run-time check is made to see if the object pointed to by expression can be converted to the type pointed to by type-id.

If the type of expression is a base class of the type of type-id, a run-time check is made to see if expression actually points to a complete object of the type of type-id. If this is true, the result is a pointer to a complete object of the type of type-id. For example:

class B { ... };
class D : public B { ... };

void f()
{
   B* pb = new D;                     // unclear but ok
   B* pb2 = new B;

   D* pd = dynamic_cast<D*>(pb);      // ok: pb actually points to a D
   ...
   D* pd2 = dynamic_cast<D*>(pb2);   // pb2 points to a B not a D
                                    // cast was bad so pd2 == NULL
   ...
}

This type of conversion is called a "downcast" because it moves a pointer down a class hierarchy, from a given class to a class derived from it.
小结：
  a     实际指向对象 和   b 目标对象,  b 是a 的 基类（子对象），或者是2者 同级转换才成功
否则 目标为NULL;也就是说不能向下转



2   多重非虚的继承模式

Class Hierarchy Showing Multiple Inheritance

A pointer to an object of type D can be safely cast to B or C. However, if D is cast to point to an A object, which instance of A would result? This would result in an ambiguous casting error. To get around this problem, you can perform two unambiguous casts. For example:

void f()
{
   D* pd = new D;
   A* pa = dynamic_cast<A*>(pd);      // error: ambiguous
   B* pb = dynamic_cast<B*>(pd);      // first cast to B
   A* pa2 = dynamic_cast<A*>(pb);   // ok: unambiguous
}

Further ambiguities can be introduced when you use virtual base classes. Consider the class hierarchy shown in the following figure.

    也就是说在2意性下会失败
3.子对象间的转换

Class Hierarchy Showing Duplicate Base Classes

    //pd 指向 e 对象
void f(D* pd)
{
   E* pe = dynamic_cast<E*>(pd);
   B* pb = pe;      // upcast, implicit conversion
   A* pa = pb;      // upcast, implicit conversion
}

//pd 指向 e 对象
void f(D* pd)
{
   B* pb = dynamic_cast<B*>(pd);      // cross cast
   A* pa = pb;                  // upcast, implicit conversion
}

  也就是  所谓 cross cast

二  typeid( type-id )     typeid( expression ) 
   此操作符返回个  const type_info & 
            expression 必须指向一个多态类型（带虚函数    ），并且要解引用

#include <iostream>
#include <typeinfo.h>

Windows objects are normally represented by HANDLEs. The MFC classes wrap Windows object handles with C++ objects. The handle wrapping functions of the MFC class library provide a way to find the C++ object that is wrapping the Windows object with a particular handle. There are times when a Windows object does not have a C++ wrapper object, however, and at these times a temporary object is created to act as the C++ wrapper.

mfc 映射的 windows object ---->c++ wrapper
以下使用 mfc 的函数 如：fromhandle, getdlgitem,都会返回temporary 和 pemanent  c++ wrapper object
 注意：
     零时的 对象 会被在空闲时(OnIdle()函数)被删除，不能存下在下次消息处理中 使用
The default OnIdle processing in CWinThread automatically calls DeleteTempMap for each class that supports temporary handle maps
////////////////////////////////////////////////////////////
The Windows objects that use handle maps are:

• HWND (CWnd and CWnd-derived classes)
• HDC (CDC and CDC-derived classes)
• HMENU (CMenu)
• HPEN (CGdiObject)
• HBRUSH (CGdiObject)
• HFONT (CGdiObject)
• HBITMAP (CGdiObject)
• HPALETTE (CGdiObject)
• HRGN (CGdiObject)
• HIMAGELIST (CImageList)
• SOCKET (CSocket)

///////////////////////////////////////////////

Given a handle to any of these objects, you can find the MFC object that wraps the handle by calling the static member function FromHandle. For example, given an HWND called hWnd:

CWnd::FromHandle(hWnd)

will return a pointer to the CWnd that wraps the hWnd. If that hWnd does not have a specific wrapper object, then a temporary CWnd is created to wrap the hWnd. This makes it possible to get a valid C++ object from any handle.

Once you have a wrapper object, you can get to its handle through a public member variable. In the case of a CWnd, m_hWnd contains the HWND for that object.

Attaching Handles to MFC Objects

Given a newly created handle-wrapper object and a handle to a Windows object, you can associate the two by calling Attach. For example:

CWnd myWnd;
myWnd.Attach(hWnd);
  ////mywnd 析构时会调用 destroywindow ,连同 hwnd 一起销毁

This makes an entry in the permanent map associating myWnd and hWnd.
Calling CWnd::FromHandle(hWnd) will now return a pointer to myWnd.
When myWnd is deleted, the destructor will automatically destroy the hWnd by calling the Windows DestroyWindow function. If this is not desired, the hWnd must be detached from myWnd before the myWnd object is destroyed (normally when leaving the scope at which myWnd was defined). The Detach member function does this.

myWnd.Detach();

More About Temporary Objects

Temporary objects are created whenever FromHandle is given a handle that does not already have a wrapper object. These temporary objects are detached from their handle and deleted by the DeleteTempMap functions. The default OnIdle processing in CWinThread automatically calls DeleteTempMap for each class that supports temporary handle maps. This means that you cannot assume a pointer to a temporary object will be valid past the point of exit from the function where the pointer was obtained, as the temporary object will be deleted during the Windows message-loop idle time.

很重要:
在多线程中传递 c++ wrapper object 是无效的(无论是 temporary 还是 permanent)
只能传递 windows handle, 换句话就是说， 线程 只能 访问 自己创建的c++ wrapper object

Wrapper Objects and Multiple Threads

Both temporary and permanent objects are maintained on a per-thread basis. That is, one thread cannot access another threads C++ wrapper objects, regardless of whether it is temporary or permanent. As stated above, temporary objects are deleted when the thread which that temporary object belongs enters OnIdle.

To pass these objects from one thread to another, always send them as their native HANDLE type. Passing a C++ wrapper object from one thread to another will often result in unexpected results.

template<class RandomAccessIterator> inline   void make_heap(      RandomAccessIterator First,      RandomAccessIterator Last   )template<class RandomAccessIterator> inline   void sort_heap(      RandomAccessIterator First,      RandomAccessIterator Last   )template<class RandomAccessIterator> inline   void push_heap(      RandomAccessIterator First,      RandomAccessIterator Last   )template<class RandomAccessIterator> inline   void pop_heap(      RandomAccessIterator First,      RandomAccessIterator Last   )

标准库 

当我还在研究院工作时，与同院另外两家研究所合作开发过一个大型水利枢纽调度集成项目。我们三家软件系统之间都要相互通信。在调试通讯模块时，细心的客户（一名好学的系统管理员）发现对于同一通信规约的解释代码，我的不超过30行，而对方的则超过了150行且很难看懂。这位系统管理员很纳闷，我说大家编程风格和习惯不一样，我使用了标准库，而他使用了传统C编程风格以及他所习惯的另外一些技术。 

别误会！我绝无贬低这位合作伙伴的意思。事实上，我对那些真正有着深厚的C编程功力的程序员常常怀有钦佩之心。毕竟，C++能有今天的成功在很大程度上缘于它深深地植根于C。作为一名C++程序员，倘若不熟悉C++中的C，我往往会认为他的基本功是不扎实的，他的技术底气是不足的。 

不过话又说回来，C++是一种多范型（paradigm）编程语言，具体采用哪种编程风格，专业程序员应该知道视具体情况而定。作为一名经常需要在现场做即兴开发的项目负责人，为了短平快地解决当务之急，我习惯尽量采用现有的库（和组件）。效率（以及强健性）久经验证的C++标准库已经摆在那儿了，何乐而不用呢？ 

Nicolai M. Josuttis, The C++ Standard Library: A Tutorial and Reference
《C++标准程序库：自修教程与参考手册》，华中科技大学出版社

这是一本百科全书式的C++标准库著作，是一本需要一再查阅的参考大全。它在完备性、细致性以及精确性方面都是无与伦比的。本书详细介绍了每一标准库组件的规格和用法，内容涵盖包括流和本地化在内的整个标准库而不仅仅是STL。正如本书副标题所示，它首先适合作为教程阅读，尔后又可用作参考手册。

浅显易懂的写作风格使得这本书非常易读。如果你希望学习标准库的用法并尽可能地发挥其潜能，那你必须拥有这本书。正如网络上所言，这本书不仅仅应该摆在你的书橱中，更应该放到你的电脑桌上。我向每一位职业C++程序员强烈推荐。

Angelika Langer, Klaus Kreft, Standard C++ IOStreams and Locales: Advanced Programmer's Guide and Reference
《标准C++输入输出流与本地化》，人民邮电出版社

C++标准库由STL、流和本地化三部分构成。关于STL的书市面上已经有不少，但罕见流和本地化方面的专著。本书是这两个领域中最优秀的一本，迄今为止没有任何一本书比这一本更全面详尽地讨论了流和本地化。如果你不满足于停留在“会用”流库的层面，千万不要错过它。

2001年夏天，我草草翻阅过这本书的中文版，从内容到包装都给我留下了比较深刻的印象 — 不过负面的居多一些。2003年秋天，无意中得知某网络书店正以超低价格甩卖这本书的中译本，情不自禁，一阵唏嘘。

Scott Meyers, Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library
《Effective STL（影印版）》，中国电力出版社

读完Scott 的《Effective C++》和《More Effective C++》的中译本之后，我一直期待这本书的中文版。我从潘爱民先生的个人主页上了解到，他和他的合作伙伴似乎早已完成了这本书的翻译工作，可惜至今市面上仍不得见。幸运的是，我们可以看到它的原版。

本书是使用STL的程序员必读之作。在这本书中，Scott向我们讲述STL容器和算法的工作机制以及如何以最佳方式使用它们。和Scott的其他作品一样，这本书的写作风格清晰、精确，具有极佳的可读性。看过这本书以后，我想你也许会和我以及其他C++程序员一样产生这样的想法：Scott什么时候会写出一本“More Effective STL”？

关于STL，我还提醒你留心Matthew H. Austern的《Generic Programming and the STL: Using and Extending the C++ Standard Template Library》（《泛型编程与STL》，中国电力出版社）。这本书散发着浓厚的学院气息。Andrew Koenig和Barbara Moo在《Accelerated C++: Practical Programming by Example》一书末尾郑重推荐另外两本进阶好书（除了他们自己的《Ruminations on C++》外），其中一本是TCPL，另外一本就是本书！

网络编程

在网络编程时代，C++应该扮演着怎样的角色，让ACE（Adaptive Communications Environment）来告诉你。

Douglas C. Schmidt, Stephen D. Huston, C++ Network Programming, Volume 1: Mastering Complexity with ACE and Patterns
Douglas C. Schmidt, Stephen D. Huston, C++ Network Programming, Volume 2: Systematic Reuse with ACE and Frameworks
《C++网络编程，卷1：运用ACE和模式消除复杂性》，华中科技大学出版社
《C++网络编程，卷2：基于 ACE 和框架的系统化复用》，电子工业出版社

采用C++进行企业级网络编程，目前ACE（以及这两本书）是一个值得考虑的选择。ACE是一个面向对象、跨平台、开放源码的网络编程框架，目标在于构建高性能网络应用和中间件。Douglas是ACE的创始人，Stephen则已为ACE提供了数年的技术支持和顾问服务，两位都是ACE社群（是的，ACE的影响和实际应用的程度已经形成了一个社群）的专家。

ACE并不单单被大学和研究所追捧，它已经被成功地应用于世界上成千上万个商业应用中。在电信、宇航、医药和财经领域的网络系统中，ACE已经并继续发挥着重要的作用。如果你准备开发高性能通讯系统，你应该考虑考虑这一汇集世界顶尖专家智慧的成果。

除了使用C++面向对象设计技术和模板等高级语言特性外，ACE还运用了大量的模式。《C++网络编程》卷1和卷2并不仅仅教你关于ACE的方方面面，它还会教给你模式和通用框架设计等高级技术等。所以，作为一名中、高级C++程序员，即使你很少进行正儿八经的C++网络程序设计，阅读这两本书同样可以从中受益。

是的，并非所有网络应用都要使用Web服务器（以及其他应用服务器）和重量级组件模型，换个思路，它们或许也可以从轻量级的ACE组件中获益。

杂项

以下这几本书之所以被列入“杂项”单元，只是因为我没有考虑出更合适的归类方法，它们和上面的书籍一样，值得一读。

Bruce Eckel, Thinking in C++, Volume 1: Introduction to Standard C++ (2nd Edition)
Bruce Eckel, Thinking in C++, Volume 2: Practical Programming (Second Edition)
《C++编程思想（第2版）第1卷：标准C++导引》，机械工业出版社
《C++编程思想（英文版 第2版）》，机械工业出版社

《Thinking in C++》的第1版于1996年荣获“软件研发”杂志评选的图书震撼大奖。最新推出的第2版对内容进行了大幅改写和调整，以反映C++标准化带来的影响以及近几年面向对象领域最新研究和实践成果。“输入输入流”、“多重继承”、“异常处理”和“运行时类型识别”等高级主题连同C++标准化以后增加的一些内容则被放入第二卷中。Bruce是一名经验丰富的C++讲师和顾问，其培训和写作经验都是世界一流水准，他的作品比那些“玩票”的技术人员写的东西更能吸引读者。事实上，在同类图书中，对于大多数读者而言，这本书的可读性要超过TCPL和《C++ Primer》。顺带一提，访问作者的站点，你可以先睹第二卷的风采。

Andrew Koenig, Barbara E. Moo, Ruminations on C++: A Decade of Programming Insight and Experience
《C++沉思录》，人民邮电出版社

Andrew是世界上屈指可数的C++专家。这是一本关于C++编程思想和程序设计技术而非语言细节的著作。如果你已经具有一定的基础，这本书将教你在进行C++编程时应该怎样思考，应该如何表达解决方案。整本书技术表达透彻，文字通俗易懂。Bjarne这样评价这本书：本书遍布“C++是什么、C++能够做什么”的真知灼见。

Stanley B. Lippman, Inside The C++ Object Model
《深度探索C++对象模型》，华中科技大学出版社
《深度探索C++对象模型（影印版）》，中国电力出版社

从编译器的角度观察C++可以使你知其然并知其所以然。本书探讨了大量的C++面向对象程序设计的底层运作机制，包括构造函数、函数、临时对象、继承、虚拟、模板的实例化、异常处理、运行期类型识别等，另外还介绍了一些在实现C++对象模型过程中做出的权衡折衷。喜欢刨根问底的C++程序员不要错过这本书。

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented software
《设计模式：可复用面向对象软件的基础》，机械工业出版社
《设计模式：可复用面向对象软件的基础（英文版）》，机械工业出版社

设计可复用的面向对象的软件，你需要掌握设计模式。本书并非专为C++程序员而写，但它采用了C++（以及Smalltalk）作为主要示例语言，C++程序员尤其易于从中受益。四位作者都是国际公认的面向对象软件领域专家，他们将面向对象软件的设计经验作为设计模式详细记录下来。这本书影响是如此深远，以至于四位作者以及本书都被昵称为GoF（Gang of Four）。本书学院气息浓厚，行文风格严谨简洁，虽然它不如某些讲解模式的书籍易读，但真正要精准地理解设计模式，本书是终极权威。学习设计模式，这本书需要一而再、再而三的咀嚼。顺带一句：请将设计模式化作开拓思维的钥匙，切莫成为封闭思维的枷锁。

还有一些C++好书值得一读，恕此处无法一一列出。例如John Lakos的著作《Large-Scale C++ Software Design》（《大规模C++程序设计》，中国电力出版社）和侯捷先生的《STL 源码剖析》（华中科技大学出版社）等。

《STL 源码剖析》是一本很有特色的书，但我认为它还可以更好。我个人期待侯捷先生自第一版发行以来经过对模板技术的沉淀和再思考之后，再写一本剖析得更深入、更透彻并且更全面的“第二版”。遗憾的是，侯捷先生在完成《C++ Templates: The Complete Guide》一书的翻译后似乎决定暂时告别模板、泛型编程和STL领域。

2004年3月31日补充：我目前最常查阅的两本参考书是《C++标准程序库》和《STL源码剖析》。当然了，这与我年内的写作计划有很大的关系。

使用C++成功开发大规模软件系统，不仅需要很好地理解大多数C++书籍中讲述的逻辑设计问题，更需要掌握《大规模C++程序设计》中讲述的