PDF《简介 0》

0

1 2 目录 简介 CppCoreGuidelines阅读笔记 开放资源 理解C++

2 简介 写这本书的导火索是发现gitbook很好用,深层原因是多年来关于C++的积累放在脑袋里总不 免哪天就人间蒸发了,不如写出来还可以产生点沉淀.

这并不是一本认真写给别人读的"书",充其量就是一个笔记集合.本身对C++就比较熟悉的人 或可以翻看一下,新人请勿当做入门材料,否则很有可能煮成夹生饭. 理解C++

3 简介 CppCoreGuidelines阅读笔记 CppCoreGuidelines是一个如何善用C++语言的指导手册,发起人之一就是C++的创始人 Bjarne Stroustrup. 指导原则 直接用代码表达想法 我想,更精确的说法是,直接用最简洁的代码表达最原始的想法. 例如,成员方法如果从含 义上看不应该修改实例状态,那就加上const修饰,明显的把这个意思表达出来;

要返回月份 就直接返回Month类型对象,而不要简单用一个int;

要在标准容器中查找就直接用find函数, 不要自己去写迭代循环;

如果能用23m/10s表达速度,就不要用一个简单的无单位2.3浮点 值. 这一条作为指导原则就意味着它必然不是特别具体可以直接指导操作的. 但是如果写代码时 总是想着用代码直接来表达自己的想法,那么写出来的代码可读性会好很多. 写符合C++标准的代码 如果有必要使用扩展,应该把这样的代码封装压缩到局部,避免这种风格扩散.能使用支持 最新版标准的编译器就使用最新版. C++标准到目前为止都有完美的向下兼容性. 这样可以 在保证已有代码能顺利通过的情况下熟悉使用新的语言特性. 表达代码的意图 这个跟第一条不太好区分,也确实有些重叠. 简单说,任何代码本身通常可以完全的表达其 具体做了什么,但是好的代码还能表达出从更高的层次看,一段代码做了什么. 个人觉得, 这两条在开始的时候最好就是大量看现有的高质量开源代码来学习.对比自己的代码自然就 能感觉出来怎样的代码表达力更强,可读性更高. 理想情况下,程序应该是静态(编译期)类型安全的 实际情况是,往往有很多情况无法达到静态类型安全. 例如滥用的联合,强制类型转换,向 下类型转换等. 它们在不必要时有一些成熟的替代方案,在必要时应该限制在局部代码中并 被透明封装. 如果能在编译期进行,就不要在运行期进行 这一条说大了就是区分静态约束和动态约束,说小了就是性能优化. 但是如果能做到尽可能 在编译期执行的话,可以在提高代码可读性的同时得到更好的执行性能. 凡是编译期无法检测的(设计约束),都应该在运行期可检测 注意,"可检测"并不是说就一定要检测,而是至少要留有检测的可能性. 尽早捕获运行期异常 理解C++

4 CppCoreGuidelines阅读笔记 如果某个设计约束被打破可能导致严重后果,那应该及早捕获异常. 而不应该装迷糊,让程 序在已经不一致的状态下继续往下执行,那样很容易出现神秘的崩溃,增大调试难度. 这里所说的捕获异常并不见得就是语法上的try catch. 也可能是判定出状态不对了直接采取 措施,而不使用异常. 所以,这一条的关键在于要"尽可能早"的处理可能的问题. 不要泄露任何资源 通常建议使用RAII来应付资源管理问题. 不要浪费执行时间和空间 如果你不在乎时间性能和空间性能,用解释型高级语言吧,开发效率还高.C++不是这么用 的. 接口 让接口明确的摆在那儿 很多时候C++里可以获取一些不直接通过接口传递的信息,例如全局变量,不过,如果你是要 设计一个接口,那么还是明确的指出来比较好让使用者理解. 原作中提到一个例外,就是像normal模式或者verbose模式这样的开关可以放到全局来做.我 个人的感觉是,即便是这些,你如果能够传递一个环境字典进去而不是直接全局变量,最终 你会受益的. 避免全局变量 避免全局单例(singleton只是全局变量的一个变种罢了) 这两条在实际操作时总是难免出问题.我愿意把这个条件稍微的降低一点. 对于可重用代 码,避免访问任何全局变量或者单例. 对于上层业务粘结代码,可以使用少量的全局实例 (最好不要有单例模式的类,即便它有全局的实例,但也应该允许主动创建多个实例). 让接口毫厘不差并且强类型安全 应该让接口表达的尽可能的精确. 不要求冗余的信息,也不使用隐含的通过其他渠道传递的 信息. 如果需要的是一个无符号整型,就不要使用int,那样使用者可能会很疑惑这个参数如 果是负数那结果会如何. 如果可以只要求一个父类型,就不要要求一个子类型. 如果只要求 一个类实例的某一个成员变量,那就不要要求把整个类实例都传进来. 如果需要一个开关, 那就明确放在参数里传进来,不要偷偷摸摸的用全局变量或者其他可能不靠谱的间接方式推 理出来. 如果需要,把状态的前提条件摆出来 原作中提到sqrt要求double参数非负,但是语言本身没有特别清晰的表达方案,所以在实现体 中一开始就用expects表明了这个约束. 我想,也可以有更好一些的处理方式.例如定义一个 PositiveDouble类型,在传入负数时抛出异常. 如果有必要,把状态后置断言摆出来 理解C++