c++程序设计语言十周年中文纪念版,今天早上到手了.
本书去年有借同事的看过一点,写的挺好的,读起来的感觉也不错,昨晚想起来了,就下了订单,希望可以慢慢的把他给读完!
书中有c++之父Bjarne Stroustrup给出的许多建议,这些对日常写程序是非常有用的,在此慢慢读着,记录下这些建议!
关于这些建议,忠告,作者阐释如下:
更新特殊或更详尽的实用规则可以在每章最后的"忠告"一节里找到.请记住,这些忠告只是粗略的实用规则,而不是万古不变的定律.它们只应使用在"合理的地方".从来就没有任何东西能够替代智慧,经验,常识和好的鉴赏力.
我发现具有"绝不要做这个"形式的规则不太有帮助.因此大部分忠告被写成应该做什么的建议,而否定性的建议也倾向于不采用绝对禁止的短语.据我所知,没有任何一种主要的C++特征没有被良好的使用过.在有关"忠告"的节里不包括解释,相反,每条忠告都引用了本书中某些适当的章节.在给出否定性忠告时,对应章节里通常都提供了有关其它的替代方式的建议.
中文版序 p.VII
我想特别强调(怎么强调都不过分)的是,应该多使用静态类型安全的字符串和容器,而不要学那些使用大量宏,强制转换和数组的编程风格.在本书中,我能够根本就不用宏,并且只在很少的非用不可的情况下才使用强制转换.我认为c/c++形式的宏是一种严重的缺陷--现在因为有了模板,名字空间,在线函数和常量这些正常的语言功能,它很大程度上更是一种多余了.同样,在任何语言中,强制转换的大量使用都是设计不良的标志.宏和强制转换是错误的主要渊薮.不用它们也能工作,这一点大提高了C++编程的安全性和优雅性.
第1章 致读者 p.13
一个人对C了解越好,在写C++程序时大概就越难避免C的风格,并会因此丢掉C++的某些潜在优势.....这里是几个有关的要点,在这些地方做同样的事情时,在C++里存在比C更好的方式:
1:在C++里几乎不需要用宏.用Const或enum定义明显的常量,用inline避免函数调用的额外开销,用template去刻画一族函数或者类型,用namespace去避免名称冲突.
2:不要在你需要变量之前去声明它,以保证你能立即对它进行初始化.声明可以出现在能出现语句的所有位置上,可以出现在for语句的初始化部分,也可以出现在条件中.
3:不要用malloc().new运算符能将同样的事情做的更好.对于realloc(),请试一试vector.
4:试着去避免void*,指针算术,联合和强制,除了在某些函数或类实现的深层之外.在大部分情况下,强制都是设计错误的指示器.如果你必须使用某个显式的类型转换,请设法去用一个"新的强制",设法写出一个描述你想做的事情的更新精确的语句.
5:尽量少用数组和C风格的字符串.与传统的C风格相比,使用C++标准库string和vector常常可以简化程序设计.
第1章 致读者 p.15
1:在编程时,你是在为你针对的某个问题的解决方案中的思想建立起一种具体表示.让程序的结构尽可能地直接反映这些思想:
a:如果你能把"它"看成一个独立的概念,就把它做成一个类.
b:如果你能把"它"看成一个独立的实体,就把它做成某个类的一个对象.
c:如果两个类有共同的"界面",将此"界面"做成一个抽象类.
d:如果两个类的实现有某些显著的共同东西,将这些共性做成一个基类.
e:如果一个类是一种对象的容器,将它做成一个模板.
f:如果一个函数实现对某容器的一个算法,将它实现对一族容器可用的模板函数.
g:如果一组类,模板等相互之间有逻辑关系,将它们放进一个名字空间里.
2:在你定义一个并不是实现某个像矩阵或复数这样的数据对象的类时,或者定义一个低层的类型如链接表的时候:
a:不要使用全局数据(使用成员).
b:不要使用全局函数.
c:不要使用公用数据成员.
d:不要使用友元,除非为了避免[a]或[c].
e:不要在一个类里面放"类型域(标志或)";采用虚函数.
f:不要使用inline函数,除非做为效果显著的优化.
第2章 C++概览 p.39
1:不用害怕,一切都会随着时间的推移而逐渐明朗起来.
2:你并不需要在知道了C++的所有细节之后才可以写出好的C++程序.
3:请特别关注程序设计技术,而不是各种语言特征.