huaxiazhihuo

      stl中最难看的组件（没有之一），无疑就是string这货了，一百多个成员函数，当然里面大多数是重载的，不必多想，一个class，如果拥有如此之多的函数，必然一定肯定是失败的，并且，即便是这么一大打函数，string的功能还是很不完备，要不然，就不会有boost里面的string算法。这真是尴尬，string作为最基本最基本的语言组件，又出自官方标准库，长成这样子，真是让无数的c++粉丝要失望，失望归失望，毕竟师出iso，用起来还是很有保障的，论性能什么，再怎样，也不会亏到那里去。只是，很让人好奇的是，这成百个函数又功能不完备的string，里面都有些什么货色，对此，c++exception系列中有过分析。但是，在此，想探讨一下，除了小胡子的方法之外，用其他方法压缩string的成员函数的数量。
      我们先来看看string的append成员函数，怪怪龙的东，总共有8个重载之多，好像还不止，突然想起狗语言的名言，少即是多，反过来说，多即是少。

        the little schemer全书行云流水，逐渐显露递归的威力，做足了铺垫，到了第8章，真命天子lambda出现，一切变得很有意思了，读完之后，意犹未尽。第9章，难度陡增，突然变得理论性起来，那是自然的。因为，这一章的主题是停机问题和Y组合算子。不引入任何形式化的方法，但是作者举重若轻，依然阐释得如此直白易懂，可以说，只要能看完前面的内容，就一定能看懂这一章。而前八章，据说6岁以上的儿童都能看得明白。

    先简单回顾一下C语言的独有的变量声明方式。自诩使用C语言多年，却一直对于C的复杂的变量声明方式头皮发麻，直到看到VCZH大神前不久的大作，才恍然大悟。惭愧，因此下面的内容颇有拾人牙慧之嫌，但为了引出后面一系列关于语言的随笔，也没办法了，本文的荣誉都归于vczh大神。就从最简单的说起。
    int a;    // 说明表达式a的值是int型，a自己本身也是int型，这不是废话吗？
    int array[N];    // 于是，表达式array[n]的值为int型，array是int数组，是否废话的味道少了一点？
    int *pA;    // 显然，*pA的值为int型，而pA的类型是指向int的指针。
    int fun(int x, int y)    // 毫无疑问，表达式fun(a,b)的值为int型，fun则是函数，其函数签名是……
    通过前面例子，说明一个道理，可以从另外一个角度来理解C变量的类型声明，先确定整个表达式的结果值的类型，再考察变量本身的类型。就好比以上几个例子，a（单独一个变量都是表达式）, array[n], *pA, fun(a,b)这些表达式都是int型，定义变量的语句的类型，其实就是为了说明这个语句的变量的整个表达式的结果的值的类型。
    好了，请深呼吸，开始重口味了，下面的注释，其实都是废话。
    int *fuck[N];    // *func[n]的类型为int，因此，func[n]的结果类型为int*，因此，func的类型为数组，数组的元素为int的指针
    int (*pfuck)(int x, int y)    // (*pfuck)(a, b)的结果类型为int，看到(*pfuck)，括号内出现一元操作符*，此物为求得指针的所指之内容，然后，此内容还能进行函数调用，因此可知，pfuck为指针，指向一函数，该函数的签名是……。当然，表达式pfuck(a, b)也可以得到相同的结果，但是，为了强调pfuck的类型，请坚持使用(*pfuck)。
    int* (*pfuck)(int x, int y)    // *(*pfuck)(a, b)的值为int，pfuck的类型自然是函数指针，函数签名是有两个int型的参数，其返回值是int*
    int (*func[5])(int *p);    // 毋庸置疑，(*func[i])(int *p)的结果是int型。它表示先获取数组的一个元素，对元素解引用，进而函数调用。显然，func为长度5的数组，数组元素是函数指针，函数有一int*行的变量，返回值是int型。
    int *(*func())();    // 心里发麻是不是，要淡定。不管怎么样，*(*func())()的结果始终都是int值，是不是？从最外围上看，*(...)()，此乃一函数调用，然后对返回值解引用得到的值为int。我们知道，C语言中，只有两物可进行函数调用的操作，或函数，或函数指针，两者必居其一。有以上例子分析可知，*(*func)()此乃对函数指针的函数调用结果求指针值。现在，又有*(*func())();，括号内的*func()，分明就表示func的函数调用，此函数的返回值为指针。结合最外层的函数调用，此返回值指针指向一函数，也就是说，返回值是函数指针。因此表达式*(*func())()，涉及到两个函数调用，它表示内层的函数调用返回函数指针，而此函数指针再调用一次，其结果为int*，再用上指针*运算符，整个表达式的值就为int了。因此，func是一函数，此函数返回函数指针，函数指针指向一个无参而返回值为int*的函数。曲折离奇，大功告成。

    好了，该反过来想了，如何从变量的类型来构造其定义语句。好比，“fuck指向一个数组，其个数为5，数组元素为函数指针，函数签名为带一个(int *p)参数，返回结果是int”。
    先考虑如何使用此变量。既然fuck是数组指针，那么，*fuck就是返回其所指向的数组，然后要得到数组的元素，自然理所当然必须用到[]操作符了，因此，就得到，(*fuck)[i]了，注意，千万切记，必须加括号，否则，*fuck[i]意味着fuck自己本身就是数组了。自己本身是数组，和指向数组，也即，数组和数组指针的差别，是相当大的，其差别之大就好像整型类型和整形指针类型。然后，必须不能忘记的是，一元操作符*就是取得指针的所指之物。
    好了，总之，对于fuck，我们通过(*fuck)[i]得到数组元素。既然元素又是函数指针，进而就得到，(*(*fuck)[i])(pa)，这个表达式的值为int。因此，答案就是，“int (*(*fuck)[5])(int *p);”。
    代码写成这样子，真他妈的贱，尽玩文字游戏，写的人费心，读的人糊涂。这该死的C语言，shit！
    文章突然长了，打住。不惜对完整的类型进行分离，以求得声明与使用的语法的高度一致性。C语言真是，真是精致得让人大倒胃口。

    又：有时候，对于稍微复杂一点声明的常用类型，会经常出现重复的声明语法，特别是在函数指针的时候，为了拟补这种缺陷，或者说是痛苦，或者说是对于变量类型的重视，C语言提供了typedef的关键字。用以代表这种声明与使用的一致性的变量的类型。在前面的例子中看到，声明语句中的类型，只是说明变量采用这种表达式时，它的就是这种类型。好比，int *pArray[20]，*pArray[i]的值为int型，但pArray却绝不是int型，为了取得pArray的类型，可借助typedef；具体的使用如下，typedef int* IntArray[20];，然后，IntArray pArray;以定义同样类型的变量。又好比上例，int *(*func())();这个函数声明好像让某些人难以理解，用上typedef化简一下，就可以重点很突出了：
    typedef int* (*FunFuck)();    // FunFuck代表无参返回值是int*的函数指针类型；
    FunFuck func();    // 作用相当于int *(*func())()，但含义更加鲜明。
    可以看到，typedef的用法很简单，不过是在过去的表达式的前面加一个typedef而已。后话，typedef在C++的template中，扮演了非常非常重要的角色，特别是模板元编程MPL中，全部的类型演算全部压在它身上，其作用之大，简直是惊天地泣鬼神，没有了typedef，C++的template不过是普通简单的泛型编程，有了template对typedef的完善支持，其实就是在struct/class内部中支持typedef语句，就导致了tmp的横空出现，导致C++的template成为威力最恐惧，同时语法也是最恐惧的泛型语言，没有之一。

    继续补充：加上const。以上对于复杂声明的理解，明眼人一看就知道仅仅是从右值的角度入手。要理解const，就必须不可不提到左值了。左值右值是C++中的基本概念，三言两语也说不清楚。最粗浅的看法，左值指可以被写入，也就是说能出现于赋值语句的左边；右值指可读，只能在赋值表达式的右边。当然，一般来说，左值往往可以当做右值来使用，可写往往意味着可读。而const的作用，就是将原本可写的东西，给整成只读的了。具体到表达式来说，就是某些表达式的值具备左右值，而const就是去掉了它的左值功能。举例说吧，还是从最简单说起。
    int a; 表达式a的结果是int型，既是左值又是右值；
    const int a;，a返回的结果是int类型，但是此结果已不再可写了，也即是a不能放在赋值语句的左边了。
    int const a; 可这样理解，先不理int const，a是一个变量，既可读又可写，const将a整成只读。int表示const a的结果类型。虽然，理解上这样，但对编译器来说，const int a;和int const a;都一样，都只是表达了同样的意思，a是一个整型常量。
    const int *p;，*p结果为int型，加上const后，*p只能读了，所以，p是整形指针，其所指的内容只能读不能写，但p本身却可写。 int const *p;，则先强调*p的只读性，然后再说明*p为int型。其实，这两种写法的意思都一样。
    int *const p;，const 紧挨着p，说明p本身只读。至于 int *，则表示*p类型为int，可读写。因此，p是整形指针，p本身不可写，但其所指的内容却可读又可写。说实在，不明白这样的指针变量有什么鬼用，实际的代码应该用的很少才是。
    为了表达指针的只读纯洁性的概念，不仅指针本身不能写，连其指向的内容也不可修改，C++终于整出了下面这样伟大的代码。int const *const p;或者const int * const p;。C++的这种做法，俗称致力于解决臆想中的问题，因为const与指针的组合，实际上只有指针所指向的内容只能读很有意义，其他的，意义微乎其微。
    可见，原本C的声明使用一致性的语法，遇上const之后，开始有点混乱了。当半路中杀出C++的引用之后，这种语法的一致性在C++中就不复存在了。C++的很多语言特性，都在不同程度不同角度，深度和广度上，形式和语义上，给C语法的精致性造成致命的各种各样的冲击。以至于，最后C++变成了有史以来很难很复杂超级变态恐怖的语言了，没有之一。

      好久没上博客了，自己的那么一点微末道行也不敢拿出来丢人现眼。实际上，过去的几年，真的是让C++和MFC害惨了，一直自个儿固步自封，说什么没有透彻掌握它们，绝不碰其他的玩意，结果就悲剧了，眼界相当重要，再怎么夸张都不为过。显然，MFC是垃圾，但实际上，C++也不是什么好菜，嗯，不吐槽了。还是做点更具实际意义的事情吧，今天的主角是键盘布局。
      由于历史的原因，当今流行的26字母的qwerty键盘布局并不是很科学，甚至有种说法，随便弄一个布局，都要比qwerty好，只因qwerty当初的设计意图就是为了最大限度的降低打字速度，这么说就有点过分了。不过，后来重新发明的布局，特别是DVORAK，的确比qwerty更具优势。但是，不管DVORAK的先天设计多么合理，如何在市场上如何造势，都不能撼动qwerty的主流地位。这很让人无语，由此可见，技术并不是决定市场的首要因素，关键是先占领市场，形成标准，不管这个标准有多差，只要有很多人遵守执行就行了，好比XX红色政党，又好比MFC，现在VC2012上居然还有他的一席之地，中国计算机图书还有那么多的VC书籍，实在令人疼心疾首。不过，本文的目的并非推荐DVORAK，当然，DVORAK键盘布局还是很值得广泛使用，但是既然已经如此的熟悉qwerty键盘了，那么也没有必要再训练了，实际上，qwerty已经足够日常使用了，我们平时打字，最大的限制在于大脑的速度，键盘布局到不是瓶颈。
      我要说的是，对于码农来说，键盘的另一不合理之处在于，小指的压力过大，左小指还好，只需负责Esc、~、……、A、Z等11个键位，先不论esc太远，这让vim情何以堪，而无关紧要的大小写切换键居然占据了那么优势明显好用之要地，等等无理设计。右小指表示压力更大，起码打了两倍，因为它的掌管比左小指的大了一倍之多，几乎是主键盘的1/4之多的键位，而且这些键，使用率都相当的频繁，如果再加上上下左右方向键还有delete，这实在太无天理了。可怜的两只小指，弱不禁风，娇怯怯，却要承受着生命难以承受之痛。相比之下，平时最能干的大拇指，居然只负责长长的空格键和两只alt这三个，这种不合理不公平的待遇，不禁让人怒从心头起，恶向胆边生，必须改革，彻底改革。给小指减负，给大拇指加负。
      当然，改革之前，先介绍windows下两大偷天换日的键盘修改利器，autohotkey和keytweak，其性能和使用说明，请各位自行百度谷歌。为了达到目的，老夫真的是挖空心思，无所不用其极。方法如下：
      1、借助autohotkey，将右手的所有键位都往右挪一格，也就是说，原来的7ujm这4个键，被发配到8ik,上，而8ik,就到了9ol.上，其他的以此类推，至于最右边的=\'/就只好屈居于开始时的7ujm上了。这样一来，小指起码少按了4个键位。右拇指只要愿意，可以不费力的按到右win键了，现在，两只拇指终于可以掌控四个键位了，四个很重要的键位，恩，目前除了space，其他三个似乎没啥特别，但很快，就会看到剩下来的三个中的其中一个，将发光发热，照耀整个键盘，最有作用。
      2、众所周知，上下左右home end 和翻页，这些键，其实也很重要，但是要按到它们，必须跑大老远，挥动右手做大幅度的机械运动。以至于，在vim和emacs中，都有各自的快捷方式来实现同样的功能。什么hjkl，什么ctrl+n，ctrl+p等等，不一而足，这种快捷方式，居然是其优于其他编辑器的亮点之一。但是，上下左右等键位可以配上ctrl、shift、win修饰键，然后马上就可以做出很多种组合，当然，emacs和vim也真是神通广大，针对每种组合，基本上都有对应的快捷键，只是记忆起来，实在麻烦。而区区在下，还曾经吭哧吭哧的拼命记忆过。好吧，好不容易习惯了vim和emacs那套逆天指法，却发现只能在vim或者emacs的环境下使用，屠龙之技，屠龙之技。我们要求的是，能够有一套放之于四海而皆准的指法，可以在所有的软件下，所有的场合下都发光发热。
      可能吗？确实有办法，就是在新键盘布局下，将右拇指能比之前轻松的按到的alt，摇身一变，变成换挡键，只要此键一按，马上wsad（游戏模式下的上下左右方向键）就变成上下左右了，配合jkl就可以组合出ctrl shift alt等效果。ec为home、end，rv则是上下翻页，f为esc键，各种各样，何其方便哉！剩下来的问题，就是右alt该何去该从，很简单，鹊巢鸠占，老实不客气，就占到右win键上，至于右win键怎么办，该怎么方便就怎么方便，甚至不存在，也没关系。制造换挡键，必须用到keytweak，autohotkey是不行的，鉴于数字小键盘上的除号实在很少用到，因此就拿他来当牺牲品了。其他的种种，请大家参考随文附上的ahk脚本。
      这样一来，只要稍加训练，键盘用起来将会很爽了。不爽的是，用别人的电脑，将特别的不习惯，各种难受。
      此外，右ctrl，可以用右掌腹来按，不必烦劳小指，他已经够累了。然后，汉字输入，要用拼音，最好是双拼，切记切记。不要在用什么五笔了，那是特别落后的输入法，其令人发指之处，可以和mfc值得一拼。在下曾经是五笔高手，下过苦功夫，多少个夏天夜晚，挥汗如雨，苦练五笔，一分钟达到百多字，绝对有资格说五笔的不是。现在我用双拼很高兴，已经不记得五笔的很多字根了，才不到半年的时间。
      其实，我都努力过，只是，都把汗水和精力，放在垃圾上了。C++是垃圾吗，当然不是了，但实际上，……，我觉得C++可以和粪便有得一比，作为肥料，还是很好地。

    好久没有上博客了，再次看看之前的文章了，觉得很难受，除了批评MFC的那篇有点意义之外，其他都是在放屁，如果误人子弟了，在下很不安，并且里面还有很情绪化的倾向，本来应该删除，免得继续祸害初学者。但是，应该勇于面对自己曾经犯过的错误，就让它留着吧，只是祈求后来者，不要再看了。
    有一种错误的认识，说什么编程语言不重要，编程思想才重要，这种认识很没有意义，何为编程思想，只怕说这句话的人也不是很清楚，至于编程思想包含了哪些内容，那更加是她没法想象得到的广阔天地。当然，思想很重要，但是，无论多么高妙的思想，终究还得靠语言来表达。而且，有些语言表达某些思想，就是要比其他语言要直接，要直白，并且所谓的思想的有些理念本身就是语言的重要组成部分，这种语言还要求学习者要经历语言的洗礼，从而尽快的掌握所谓的编程思想，以便能初步使用它。然后，又有些语言天生残疾，无论如何整顿，就是没法表达某种编程思想，好比JAVA。总之，语言的选择，应该是很严肃的问题，不可等闲视之，至于思想，那也是通过具体的语言才能领悟。
    不管对于C++有多么深厚的感情，但是，确实没必要让自己吊死在一个树上。走出了那片天地，开阔视野之后，再回来，可以更好更快的处理原来领域上的问题。所以对于有志于CPPER，就是不要再C++各种语言细节上死钻牛角尖，必须多学习几种语言，吸收他们的优点，然后回来拟补C++本身的很多不足，学习其他语言，其实也是在学习C++，并且是更好地学习之法，因为这样，才能了解到C++的不足，才知道为了拟补其先天的不足，是怎样的努力，才设计出那些逆天的语言复杂性。
    个人感觉，C语言弱智（将太多的事情交给程序员来做，美其名曰信任程序员，搞得码农一天到晚死钻细节，又由于语言的抽象能力严重缺乏，所以很多事情就是吃力不讨好。当然也要承认，人写出来的代码，始终要比编译器出来的要好要可控，起码某种形式上，但是有必要吗）。至于C++，的确强大，自由，但是，她真的是丑陋无比，由于本身的野心过大，导致其语言核心无比的模糊，想要很好的使用，必须深刻系统的学习其静态类型系统和各种类型演算，因此，模板元编程必须基础十分扎实,不是为了用MPL写代码，而是学了之后，才能更深刻的感受到C++的类型系统（某些人十分反感template，不知所谓，殊不知，没有了template，C++的威力将降低一大半，还有，C++的各种奇技淫巧和宏，也在template这里大放惊人异彩。学了C#和java的泛型之后，才惊诧C++的template的功能如此的变态厉害，所谓的图灵完备，原来是这么回事）。此外，还要知道C++的种种不足，比如GC，比如严重残缺的动态类型信息，比如……（好吧，想不出来了），但是，这些都不是问题，C++非常神奇，对于语言上的种种不足，通过有些人种种奇技淫巧，历经千辛万苦，终于可以实现了，但是，最后出来的东西，始终还是没有语言层面上直接支持的来的好，并且有些还不免很丑陋，这是必须的，不过，C++11出来之后，语言的各种不足，都有不同程度的改善，造轮子时可用的材料也多了，最后，得益于C++11的新特性，轮子的外观也可以更好看。
    C++的学习教条，当然，重中之重，是，恳请不要学习C++，现实的很多很多问题，都可以不必C++来搞，那些嵌入式的东西，与硬件紧密相关的，C其实很能够胜任了，其实，C还是很好地。
    1、忌将精力都放在C++上，多学习学习其他语言；2、忌学MFC，这个东西，碰都不要碰；3、不要用C++解决所有的问题，很多问题用其他语言来解决效果会更好，无论开发效率还是运行效率；4、眼界很重要，……。作为C++的死忠，说这些实在有悖于对C++的感情，其实也不是，只是曲线救国之法，因为，要驾驭C++的种种奇怪的复杂，的确需要C++以外的视野。C++的确不是人人都能使用，合格的C++猿不但要拥抱奇技淫巧，还要能发明出更好的奇技淫巧，没有最好的奇技淫巧，只有更好的奇技淫巧，C++就是用来创造奇技淫巧的。
    窃以为，对于语言学习者来说，特别是C++猿，以下几种，C#的实用，scheme的优雅，haskell的严谨简洁，都有必要的学习学习。对了，还有smalltalk，但是考虑到面向对象本身的问题，就不推荐了。至于其他语言，在下接触不深，就不敢多嘴了。对了，还有设计模式，这东西还是很好的，特别是在面向对象的时候。至于以前说到的消息发送，纯属无稽之谈，这东西反人类，那是由于C本身的抽象能力不足，才搞出来的一个怪胎，无奈之举。对于比C更高级的语言，完全没必要再模仿了。设计模式的一大特点在于把模式的实现完全固守在静态类对象上，这样理解起来确实方便，但是，带来的问题，就误导了某些无知的读者，以为必须一定要用静态的面向对象的语言（在这一点上，JAVA是最彻底的实践者）来实现模式，以至于，为了实现模式，要写很多很多不必要的狗屎般的代码。其实，设计模式只是思想，书中的实现只是示范而已，大伙儿不必死盘硬套。对了，对于C++沉思录那道著名的例题，用设计模式做出来的效果，始终感觉很别扭，较好的思路是组合运算子。
    互联网上的有害信息真多，很不幸的是，之前写了那么几篇狗屁不通的文章，实在惭愧。

        本来只想对C++赞叹复赞叹，后来就失控了，接着情绪化了，最后终于开始爆走，语无伦次。
        平心而论，C的而且确小巧精致，一切通通透透。老夫真心喜欢用它来编码，但一旦动用真格了，就立马叶公好龙，就会怀念C++的种种好处，class、 template、 virtual、 析构函数、甚至异常、const、引用等等，原来，离开了之后，才明白你的种种美妙动人之处，因此，朕已决定，有生之年，假如还在编码，那么C++，在心目中的，将是无可替代，它的一切，即便缺点，也是那么地令人回味无穷。因为它的一切，将自由贯彻到底，充分尊重用户的选择，不轻易剥夺用户的权利，更不强求用户用什么样的方式做设计。所谓自由的世界，独立的人格，手持C++利器，虽不敢说横行天下，但起码能愉快地编码。只有C++，当一个人独立使用，如此的耐人寻味，历久常新。多人一块开发，简直是大灾难，没必要的封装，种种自制的破烂轮子（前几年，出自本座手中的轮子不计其数，基本上惨不忍睹），错综复杂，交叉引用的类关系。这在其他语言中难以出现的怪现象，在C++中，平常得很，再一次证明了C++的博大精深，包罗万象。不说别的，就说C++中的最负盛名GUI框架MFC，其类层次的设计，糟糕透顶，而BCG的代码注入，毫无创意，笨拙无比的命名，垃圾般狗屎般的代码堆积，可怕的内存消耗，令人眼界大开，MFC的资源消耗已经够厉害，相比之下，居然显得那么节俭，而用BCG开发界面，居然比C#又或者JAVA做出来的软件，还不卡，这一切，都证明了C++过人之处。爱死你了，C++。
          近几年来看到某些人不知出于何因，对C++横加指责，说什么论效率不如C，论高级特性又不如其他的动态语言，实在莫明奇妙。说什么C++中的inline、继承、template破坏了模块的分离，“用C语言1000行源码能完成的工作千万不要用C++重写！”，实则用C++来写根本就无须1000行，并且可以精简那些字数多的代码行，并且还更加易读易懂，更加容易维护，效率或许还能更快一点点，得益于内联。如果还觉得用C++写1000行代码没有C那么漂亮，那只证明阁下没能力驾驭C++，请不要对C++乱加指责。他们那些所谓的C高手的代码，到处指针飞舞，又长又臭一再重复的表达式（本该内联大显身手），着实让人难受，当然，不否认他们的精妙设计。
        纵观他们对C++非议之例子，无一不暴露出其设计上的缺陷，本该成员函数指针大显伸手，他们却用上了虚函数；Template模式的函数（顺序依次，调用几本虚函数），本该做成全局函数，硬是整成员函数；多继承中的钻石抽象基类不该有任何东西，他们却偏要放某些东西，最后没办法，在虚继承中纠结。……所有这一切根本无损于C++，却只显现出他们的愚蠢与无知。想展现自己也言行独立，到头来却做出拾人牙蠢之事。其实，他们更应该感谢C++，是C++的包容，才容许了如此丑陋的设计。本座平生最不齿这群宵小，自己毫无主见，风闻名人几句惊世骇俗之话语，就跟着瞎起哄，国人的毫无道理的盲目跟风，由来已久，也不必细表了。那些所谓的C高手，觉得用C能做出精妙的设计，为何用起C++就不行了，其实他们大可“用C做设计，用C++编码”，这样，根本就不会影响他们的伟大杰作构思。
并且要做到如同C那样的高效，C++中完全没有问题，完全可以放下身段，将C++的抽象降低到C那样的级别，在没有独立完整的概念之前，或者是没有很好的理由，绝不用类来封装代码，禁用慎用C++的一切高级特性，好比虚函数、继承、异常等。任何语言特性都可以写出垃圾代码，也容易用得不好，但不可因为这样，就否定此种特性的价值。特性作用越大，就越微妙，就越容易滥用误用。即此而观，C++中，应该以class最为难用，此关一过，必定神清气爽。
的确，C中，你可以也必须面对一切细节，在这种恶劣的环境下，手上能用的武器，也只有函数、结构体、数组和宏，程序员的潜能就这样被迫出来，爆发出来了，做出最合乎本质的设计，而这几样简单武器，互相组合，居然可以用得如此出神入化，其效果鬼斧神工，巧夺天工，直可惊天地，泣鬼神，手法更是精彩缤纷，巧妙绝伦，令人目不接暇，但是，不管如何，始终缺乏管理细节的有效武器。
       鄙人最惊叹C++的一强悍之处，对于各种匪夷所思的变态问题，会有更加变态的解决方式，而且还不止一两种，更可见其灵活多变自由丰富的个性，但众多迥异特性又能如此和谐的共存，为什么？窃以为C++是强类型的静态语言，虽然提供多种语言工具以让码农愉快轻松地编码，尽可能地在编译时期发现更多错误，各种微妙的语言特性不过是为了帮助码农愉快高效地编码，少出错，他们可以用这些语言工具整理组织C的各种凌散的表达式。
因为C中虽然能直面一切细节，却缺乏管理细节的语言工具。所有C中的细节，几乎可通过C++的各种丰富特性妥善整理，而效率的损失又甚少，并且，在其强大的静态系统的分析，能多发现点问题。但是强类型只是工具而已，必须善加利用，但C++的码农不会受束缚，必要的时候，大可突破。鄙人就曾经实现了一个微型的动态系统，对象之间没有用层次关系，都是平等的，但之间又能互相组合装配拆除，达到多继承的效果，又没有多继承的各种问题。虽然语法上别扭点，但习惯了就感觉挺不错。
       要看到C++的对C代码的变态重组，为此，随便举例，qsort是代码上的典范境界，能排序所有的数组，只要提供了元素之间的比较函数，就能快速地排序，实至名归。但它是弱类型，其正确性全靠程序猿手工输入，参数出错了，编译器也检查不出来，当然C高猿不大容易出错。只是，依赖于C++强大类型推导威力，通过template整成以下样子，既不限制qsort的包容性，又不损失任何一点点效率
template<typename _Ty>
inline void Sort(_Ty* pItems, size_t nItemCount, int (__cdecl* funcCompare)(const _Ty&, const _Ty&))
{
    int (__cdecl * _PtFuncCompare)(const void *, const void *);
    union_cast(_PtFuncCompare, funcCompare);    // 为忽弄编译器的强类型检查
    qsort(pItems, nItemCount, sizeof(_Ty), _PtFuncCompare);
}
 但已经是强类型的了，C++猿用起来就不大容易出错了，并且元素的比较函数也更加容易编写，没必要再用指针了，个人而言，引用比指针好，最起码少敲一下键盘，那行代码的长度可减少了一个字符。这样，用起来不是更爽吗？
      又好比消息循环，判断消息类型，一遍又一遍地写着重复的表达式，好比，msg.message==WM_LBUTTONDOWN，不好玩，干脆class一CMsg，继承自MSG。好比这样：
class CMsg : public MSG
{
public:
    bool Is(DWORD nMsg) const{ return message==nMsg; }
};
         于是以上的那行判断语句，就精简成msg.Is(WM_LBUTTONDOWN)，感觉应该好点吧。这两例的代码整理手段，对C++来说稀松平常，但C中就做不出来了，大概也只能用宏了，但宏的问题，大家也知道。
        又有人说，C++高手的修成要经过两次转换，从C到C++，然后从C++回复C，实在异想天开，不值一晒，舍弃C++的强大类型检查，欲与一切细节肉博，吾不见其高明。这不是什么C++高手，充其量也只是C高手，其苦心孤诣在C中模仿C++的面向对象的伎俩，用C++来表达，不过小菜一碟，并且还不失强类型检查，必要时，只须用联合体或类型转换忽悠编译器。那些回归C的高猿的C++代码，其实，不甚精致。所以，大家也不必理会。只须老老实实地做出简简单单的设计，然后再用C++组织管理各种细节，大可将代码写得漂漂亮亮干干净净。
         要谨记的是，只用那些熟悉有把握的语言特性，对于每一个用到的C++关键字，一定要清楚其背后的机制并且由此所带来的各种副作用。最难用的就是class了，毫无必要的封装， 比赤裸裸的代码更加丑陋，请优先选择非成员函数。封装的出现，是因为代码的一再重复出现的需要，而并非想当然地推理演绎。只要是重复代码，不管是一行表达，连续多行，分散跨行，都可以给予包装在一起，只需一个函数调用。
          再次重温C++的核心设计，尽可能利用静态强类型，尽可能地在编译期中找出程序的错误，提供多种丰富特性，协助码农充分地发挥强类型的一切优点，对抗一切细节，对抗一切重复代码，并且不必付出任何不必要的代价。当然，强类型只是忠实的奴仆，完全不必因为它而迁就你的设计，想要忽悠它，方法多种多样。 有人说，C++的语言特性太凌散，不系统，好像打补丁似的。但鄙人觉得挺好的，特性分散，各自为政，可随意自由组合，你讨厌某个特性，大可不必理睬，它就静静地站在一旁，丝毫不影响你的代码，这不就是设计的最高境界吗。
        好了，终于狠狠地出了口恶气。在下承认很情绪化，有失高手风范。

    请容许先发一句牢骚，“这万恶的成员函数指针的丑陋语法！”，C中的函数指针的语法已经够难看的了，但相比之下，成员函数指针却更加不堪入目，使用上又很不方便，很不人性化，简直是只能行走寸步。只可惜，函数指针的作用实在太大了，忽视不得。
    大家都知道，函数指针（或又叫回调函数）是上层模块和底层模块进行通信的最佳手段，上层通过提供函数指针给底层，以使得底层在适当的时候，可以调用执行上层的代码，C库中的qsort足以说明这种使用，qsort在排序时，不知道如何比较两个数组元素的大小，必须通过上层提供的大小比较函数来进行比较。此外，操作系统提供的API中，有多少地方使用上了回调函数。假如没有函数指针，这简直没法想像，日子没法过了。函数指针是实现模块分层的不二法门，当然接口也可以，但是，用户代码必须继承或者实现底层硬性规定无理取闹的虚函数，本来很轻量级的POD，再也不轻快了，实在颇不方便，不，简直很有点恶心。说来说去，还是函数指针好。
    既然，C中的回调函数这么重要，那么，可想而知，进入C++中，整个世界到处都是CLASS，将回调函数这个概念推广到CLASS上，也即是成员函数指针，将是多么迫切的事情。理论上，可以将成员函数指针视为函数指针的语法糖，只要规定函数指针的第一个参数为void* pThis，然后在函数指针的实现函数中，进行类型转换也能满足使用，在很长的一段时间里，因为这种方式的简单清晰，一直都用这种方式代替成员函数指针。但是，一遍又一遍地被迫编写重复代码，特别是枯燥的类型转换，任何人都无法忍受。因此，决定直面这个问题。
    理论上，成员函数和普通函数一样，在内存中，都有自己的位置，只要有了地址信息，就可以通过指针来获取，保存起来，然后在未来的某个地方，通过这个指针来执行函数中的代码。差别之处，在于，调用成员函数前，要先将this推入ecx中，很久之前，成员函数指针确实和普通函数指针一样简单，只是后来，虚函数和多继承出现之后，简单的指针信息再也承载不了成员函数的重量，从此之后，.......（忽略，请大家自行BAIDU）。总之，C++中，成员函数指针并非指针类型，理所当然，也就不支持指针的大多数操作，比如，赋值NULL，或者类型转换。因此，所有能够让函数指针大放异彩的种种手段，在这里，都用不上了，原本在C中光芒四射的好东西，到了C++中，竟然黯然失色，所有本该让函数指针大显身手的地方，大家都绕道而行。
    逼急了，也有尝试突破，MFC的仅仅作了有限争取的手段（为了这一点点好处，MFC可不知作了多大的努力），居然成为其消息映射的基石。但是，据说，MFC的成员函数指针的设计也非出于自愿，而是因为消息太多，实在没法整成虚函数来处理，每个窗口类背负成千上万个函数的虚函数表，可不是省油的灯。为了努力地支持虚函数和多继承，C++的编译器不惜在成员函数指针的使用上设下种种阻拦，令人又气又恨。而更加令人不解的是，C++横行天下十几年，函数指针似乎长期得不到重视，大师们都在面向对象上探索，很多本该成员函数指针发光发热的地方，几乎都退位给虚函数了，并美其名曰策略模式又或者是其他的什么模式，不过是换了一套更加难看的马甲，却又那么好听的名字，不，不好听，只要听到模式两字，就令人大倒胃口。所有大用特用模式的代码，如果用非模式来实现，其代码量将少掉很多，而且还更具扩展性，这是真的。先透露一下，正在构思一文章，将深度介绍模式，专注于WHY，并且类比现实，兼扯上WINDOWS、COM和MFC对模式的应用，说句良心话，如果只用接口来做设计，模式绝对是好东西。只可惜，接口其实是SB。写底层代码，如果要求用户必须实现某些接口，又或者是继承某些类，改写虚函数，这种侵入式的设计，实在无理取闹之至。
    后来，大伙儿也终于开始重视成员函数指针，特别是C#的委托出现之后，网络上更是充斥着各种成员函数指针的版本代码，都可以很好地完成任务。特别是TR1又或者是BOOST中的function，功能相当的强悍得令人非大吃一惊不可。只可惜，大多数情况下，用户只想填饱肚子而已，但是BOOST或者其他的类库却硬要来一桌满汉全席，这也罢了，但是，它还要用户额外买单，并且还真不低呢，这就很让人受不了啦。其实，一般情况下，我们的要求不会太过分，仅仅想要针对普通的成员函数指针进行回调，它却为此在其内部new一个内部类出来，假如大规模使用，后果将不堪设想，其实也没那么严重，完成是C++迷们的强迫症。
    但是，说真的，实在希望很精简，不要生成不必要的虚函数表，不要模板生成不必要的函数（没办法内联，有函数地址的那一种），只要求它如同对待C中的函数指针一样，参数入栈和一个简单的函数调用的指令，外加将this推入ecx即可，就好像直接调用成员函数那样就好了。好了，贡献上代码了，史上最轻量级，精简无比的成员函数指针，功能也最弱了。对不起，代码并不完整，实际的代码，用上了宏，所谓的宏的图灵完备。在下很懒，一向只介绍想法而已，只于具体的实现细节以及语法考究，窃以为，每个C++迷们应该完全能够胜任。俗话说，高手只要求创意就行了，本文详细介绍算法并给出代码，已经落了下乘。
    这个实现，不考虑多继承，忽略了虚函数，也不支持非成员函数（也可以用上，只是，要多做一点点手脚，以下将给出示例，而且，普通函数指针已经完全可以胜任），只集中火力专注于普通成员函数，毕竟，在下的运用中，它占上了95%以上，所以才能如此的高效。单一职责啊！
    此外，本文参考了《成员函数指针与高性能的C++委托》、《刘未鹏的BOOST源码解析》、《C++设计新思维》，请自行GOOGLE。

    毫无疑问，shared_ptr的功能不可谓不强大，设计不可谓不精巧，它的抽象级别不是一般的高，不仅要管理一般的C++内存资源，更染指其他的非C++资源，比如文件、比如连接、……，只要给它一个支点（释放资源的函数），不仅如此，还能顽强地生存于各种恶劣的环境，好比多线程、引用循环。当然，代价是有的，它背地里做了很多不为人知的勾当，表面上仅仅一行的带有构造函数shared_ptr的定义代码，编译器却要很无奈地生成一个莫明其妙的多态模板类（_Ref_count_base的继承类，带有虚函数表，意味着不能内联，用以在恰当的时机，释放资源），更别提要多了一堆指令，当然，在当今硬件性能蓬勃发展的美好时代，这点代价根本就不算什么，比之于那些什么所谓的虚拟机，甚至可以忽略不计。但是，总是有那么一批老古董，总会强迫假想自己写的程序会运行于各种资源非常苛刻的环境下，内心就是没法原谅shared_ptr所带来的极细微的损失。好比区区在下，每一次一用到shared_ptr，心里的那种负罪感啊，又多了几条废指令，又浪费多了十几个的堆字节，是否将生成内存碎片啊。终于有一刻顶不住了啦，去你妈的shared_ptr，老子不过想让你老老实实的代理内存资源，本本分分地做好你的分内之事，不劳你费心照顾其他的系统资源对象，那些场合本座自然有更好的解决方式。于是，制造轮子的悲剧又再次诞生了，虽然，他们一直在内心深处抵制新轮子的愚蠢行为，但是，……，只能说，知我者谓我心忧，不知我者谓我何求。
    每次想到shared_ptr要new一个_Ref_count_base的对象来管理计数，有人就恨得牙根发痒，巴不得把_Ref_count_base的数据成员搬过来，放之于那个要管理的对象的身上，以减少一小块内存。假如，客户传到shared_ptr构造函数的指针，此指针所指的内存，能再多几个字节（一个字节也行，最大值255，已足矣），以供我等存放一个long型的计数器，那就好办了。白痴也知道，这是不可能的事情。除非，此对象由shared_ptr来构造，那么还有办法再放多点额外内存进去。此话怎讲？大家都知道，C++中， new一个对象时，即意味着两步操作：1、分配一块内存；2、在此块内存上执行对象的构造函数。如果第1步的分配内存，能作多点手脚，比如说，分配一块比对象本身所占空间还要大的内存，那么我们的shared_ptr就可以把计数器放进对象之中了，也无须再new一个新的_Ref_count_base对象来管理计数器了。两块内存，合二为一，双剑合璧，妙哉妙哉。但，这如何做到呢？
    以下，是一个类从简单到复杂的物种进化历程。C++中，只要是通用类，即使再简单的需求，要写得可以被普遍承认，可以高高兴兴地到处使用，都绝非易事。而且，更悲剧的是，辛辛苦苦，呕心沥血造出来的轮子，还很有可能一问世就直接被枪毙，就算能苟且活下来，也不会有车愿意组装这一个废轮子。
    废话不说，书接上文，很明显，对象的new操作应该由我们的shared_ptr来掌控。任由用户来new，就太迟了，对象的内存块已经确定下来了，没文章可做啦。换句话说，shared_ptr必须模拟标准的new的两在操作分配内存和调用构造函数。由此可知，以下所探讨的shared_ptr运用场合也很有限，只适合于那些能看到构造函数并且知道其大小的C++类，所以，请大伙儿不要抱怨。唯其需求简单明确，所以才能高效。
首先，用一结构体__SharedObject来包含计数器和对象，如下所示：
    是否很简陋，本座没法也不想把它整得更加好看了。
    我们的shared_ptr，就暂时叫TShared_Ptr好了，其包含的数据成员，暂时很简单。就只有一个__SharedObject的指针而已，后面由于多继承多态的原因，将被迫多增加一个指针。
    好了，先看看TShared_Ptr的使用之道，此乃class template。由于共享对象由TShared_Ptr所造，所以，在其诞生之前，首先势必定义一TShared_Ptr变量，好比，TShared_Ptr<int> pInt；考虑TShared_Ptr的构造函数，如果在里面就急急忙忙给共享对象分配内存，将没法表达空指针这个概念，所以它的无参构造函数只是简单地将m_pShared置为NULL。然后，TShared_Ptr必须提供分配内存并执行构造函数的操作，叫Construct吧；然后，析构函数也绝不含糊，执行对象的析构函数并释放内存。于是，TShared_Ptr的基本代码就出炉了。