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

你可能感兴趣的:(C++,c,C#,OO)