STL,我对它的思考和学习(纯粹谈思想，不谈语法技术)

首先，学习一个东西一顶要弄清楚它产生的背景，和他的特性在哪儿。先来看STL的特性，编

译期的动态。也就是说，根据类型来推导出代码的语法生成。如果你够聪明，你肯定会联想到

C/C++一些静态编译的东西，比如全局，比如static,比如enum,那么是否可以利用STL特性和这

些东西结合起来，弄出有意思的东西呢？比如让enum的值等于一个模板函数，比如在static函

数里做点判断。那么一些数的取值在编译器内完成，甚至打印出东西，也不足奇怪了。

其次，STL背景是某某人突然思考，对一个四则运算来说，提供的接口不应该根据类型不同而

重新设计，进而有了STL的概念。也就说，在STL提倡的背景里，所带来的思想是：在程序里，

任何东西都是数据+存储空间这么个概念，而存储空间是个抽象的概念，不应为数据的变化而

变化内部的操作。你见过一间房屋可以放下桌子，如果送来的是个箱子，就必须提供个货仓

吗？支持这个之上的，是人类不以计算机语言做为基础思考而衍生出的思维。反过来说，STL

提倡的正是一个OO数据处理的一个概念，而不是OO设计，甚至对OO设计没有任何挂钩(数据处

理和设计也有若干的交纵)。

最后，STL的语法糖衣确实非常的烦琐。为什么用得人少？我以为，在

语意数据的解释上，STL自相矛盾了。熟悉C的人都知道，无论多么抽象的对象和需求的表达，

操纵的都是内存的字节流而已。在接口简便的处理上，大家更宁愿使用typedef int,float,或

者class这样的数据类型做为接口，因为这已经够简洁了，有时候需要的并不是对所有数据的

容纳。对不同数据容纳，比如你用个class A的接口，现在却改个 class B，随之的绑定是内

部处理方法也不一样了。如果能将这些糖衣的语法(typename 之类的)改成像解释语言般的var

来表达，就显得简单易用得多了。毕竟这种语法的推导C++的一个特性，而不是它的一个功能

化。

---昨晚睡觉又想了下，进行补充
范型这个概念的提出肯定是对的。但是C++这种语法的实现，给人许多语法纠结的陷阱，虽然很强大，但是个人认为远不如java的舒服。其次，BJ博士说过，看到一个需求和问题，就应该用Class和STL不由自主的组装起来，也就是说，当有一天能够把逻辑的处理（比如OO的设计）和数据的容器（STL）随心所欲的结合起来的时候，就是小成了。


(一家之言，请莫恶意相加。我的最后一点想的不是很深入，但是我能感觉到范型做为OO数据处理带来的影响)


2009-9-22 0:16:12补记
    C++ template是本好书。但可惜，越高级语言的应用书籍冗余性太多，尤其是外国的经典。作者都是拼命的把读者看成一个傻瓜，这对于一个入门的新手很合适，但是对于有基础，并且有自己一套学习方法的人很反感。
    看完第一二篇后，我自己总结了一套语法规则，和一些重载的优先的。并且特别好奇的看了编译可以直接查找的特性(这个绝对是个副产物)。基本的几点我也总结上，到后面的几篇，我发现无一例外都是在告戒这些东西和注意点。实在是很没意思。。刷刷刷直接翻到最后几章。
    那么我现在的学习方法是，多从一个例子里总结用到的技术方案，多怀疑，多尝试，你从一个例子里得到的越多，你也越省时间，也越锻炼自己。剩下的就是多编码经验，书都是次要的了。什么书应该认真看？纯理论的。。
    我之前也简单说过，你真正掌握和吃透技术，不是知道他的技术点，而是了解他要给予的你思想，然后综合产生你自己的思想信仰。