斯巴达的勇士已经是雅典的臣民了。。。

还是不错的一章。尽管看了也用过了挺多的Smart Poniter了，但是看到这章还是引发了很多的遐想。首先第一点，并非所有的只能指针都需要重载->和*这两个操作符，甚至要禁止这样的操作符，道理很简单。像操作系统中的这些Handle，这些东西本身就是访问系统资源的一个标记。并没有什么实际的成员函数，所以对他们而言，这样的* ->没有什么意义的。而如果要控制这些的访问级别，无疑反复提到的policy模

说来惭愧，大学没有好好学，第一次听到这个所谓Singleton的时候是在一个校园招聘会上。大致的题目就是要写一个Singleton，答案么大概也可以预计，就是什么都不知道， 呵呵。时过境迁，也写过了一些这样的东西，现在回过头来，还有很有意义的。不搞的特别另类，还是循着书中介绍的顺序来看看吧。// Header file Singleton.hclass Singleton{public:     

    说到Funtor呢，应该是STL中比较普遍使用的一个东西。大致的意思就是把一个类对象像函数一样的使用，当然这个类需要重载()操作符。因为他比较像函数，所以得了一个Funtor的名字，至于翻译好像主流的叫函数子？？有点搞不清状况。还是看一个最简单的Funtor的例子吧// test functor classtemplateclass T> class plus{

 紧接这上次没说完的来说。上回我们介绍了最基本的brute-force方案。那个安全的类型遍历匹配方案。说到在类数量比较多的时候不一定高效。很简单的可以知道原来的时间复杂度是O(n)，n就是类的数量。所以估摸这转化成O(log(n))应该差不多了。所以这个第二方案就是用关联性的容器来替代依次遍历。我们把这个方案称之为The Logarithmic Double Dispatcher. 就像Scot

开始的第一方案的查询时间达到了O(n)，我们认为在类的数量比较少的时候是可行的。在进入了第二方案的时候，我们让查询速度时间缩短到了O(log(n))，如果我们要在这里更进一步的话，那就应该是O(1)了。在这里我们就继续推出这个所谓的常数时间方案。在第二方案的时候，我们需要对数时间的比较来得到答案，如果是常数时间，那必须摒弃这种比较。参照前面的思路继续往下，前面的map如果改成hashtable

如果说前面我们已经把武功练到了第十重境界的话，最后一章意味着我们马上要打开任督二脉，一夜飞升了：）基于这样的关键的时间点，我们愿意非常谨慎的把这个问题分三次慢慢的讲，讲清楚。这第一次我们将说到这个MultiMethod话题的开始和第一个解决方案。这个MultiMethod的问题源自于C++不支持多参数的函数多态，（其实原先我不觉得我们有这么多这样类型的需求，但是当看到不知道起什么名字的时候我相

从开始学习设计模式的时候,就有一个概念,visitor是一个鸡肋模式.由于visitor模式对于类结构稳定性的要求非常高,所以其实自己感觉在现实生活中的运用很少.(在现实中一般总可以,或者总趋向于添加一个虚函数接口了事).当然visitor不止现在这个问题,另一个突出的问题就是循环依赖.这对于C++来说,或者说对于OO来说都是一个尴尬的问题,在>中也提及了"第22条　尽量减少定义性依赖。避免循

在频繁的new/delete的时候容易衍生memory fragment, 我想设计这个Allocator的初衷就在这里。初看到这个题目的时候不由的让人联想到的东西是std::allocator.  所以我们就从MS的STL中看看std::allocator的实现。templateclass _Ty> inline    _Ty _FARQ *_Allocate(_SIZT _Coun

 套用一个现在很流行的句式，（好多什么编程之美或者代码之美的）。我想看了第三章Modern C++ Design能感受的就是递归之美。而其中主要介绍的TypeList就是这样一个递归演绎的完美的例子。其实TypeList本身的定义非常简单。就是一个有Head有Tail的一个简单的空的定义template struct Typelist { typedef T Head; typ

Chapter 1, Policy-Based Class Design如果说自己的知识领域是一个圆的话， 那么随着你的知识越来越多，周长也就越长。换言之，和你不明白的知识交集越大，也可以说自己越发觉得无知。这就是翻了几页这本《Modern C++Design》之后的感受。好像给自己打开了一个新的空间， 原来C++还可以这么写:)。这样的惊喜从第一张Policy-Bas

再没有读这章的时候就在想，上一章是factory那这章是不是就是Abstract Factory了。果不其然啊！一样的，在开始描述之前，援引wikipedia的定义来看看：A software design pattern, the Abstract Factory Pattern provides a way to encapsulate a group of individual factor

惊艳的效果还在继续，第二章开始讲到了一些基本的传统的（但是我居然还是不知道的）技法，利用模板的编译特殊编译特性带来了些新的帮助。有印象的东西就是Compile-time assertions, 和Traits。Assert是个很奇特的东西，说实话就是在debug的时候有点用处，因为在release中如果Assert失败抛出个什么错误对话框也一点都不makesense。但是如果可以帮debu

在前面一章的描述中说实话有点浅尝辄止，淡淡的扯了前面几节就黔驴技穷了，当然也不想再狗尾续貂了，所以很高兴开始了新的一章的征程 Object Factories。说起这章，我们得先说说Factory模式， 这个模式的起源在于我们有太多的类似ConcreteClass* p = new ConcreteClass 的申明，而这些静态的申请在这里限定了p的类型， 我们的想法就是如果可以不显示把p

#include using namespace std; /* Place holder for thread synchronization mutex */class Mutex{   /* placeholder for code to create, use, and free a mutex */}; /* Place holder for thread synchronization