高质量程序设计指南 C++/C语言（第3版）（修订版）pdf

高质量程序设计指南 C++/C语言（第3版）（修订版） 作者：林锐，韩永泉

高质量程序设计指南 C++/C语言（第3版）（修订版） 出版社：电子工业出版社

高质量程序设计指南 C++/C语言（第3版）（修订版） 内容简介

高质量程序设计是软件行业的薄弱环节，大部分企业为此付出了高昂的代价，只能通过大量的测试和改错来提高软件产品的质量。因此，如何让程序员熟练地掌握编程技术和编程规范，在开发过程中内建高质量代码，是IT企业面临的主要挑战之一。

《高质量程序设计指南：C++/C语言（第3版）》以轻松幽默的笔调向读者论述了高质量软件开发方法与C++/C编程规范，而这也是作者多年从事软件开发工作的经验总结。全书共17章，第1章到第4章重点介绍软件质量和基本的程序设计方法；第5章到第16章重点阐述C++/C编程风格、面向对象程序设计方法和一些技术专题；第17章阐述STL的原理和使用方法。

本书第1版和第2版部分章节曾经在网上广泛流传，被国内IT企业的不少软件开发人员采用。本书的附录C《大学十年》是作者在网上发表的一个短篇传记，文中所描述的充满激情的学习和生活态度，感染了大批莘莘学子。

《高质量程序设计指南：C++/C语言（第3版）》的主要读者对象是IT企业的程序员和项目经理，以及大专院校的本科生和研究生。

高质量程序设计指南 C++/C语言（第3版）（修订版） 目录

第1章 高质量软件开发之道

1.1 软件质量基本概念

1.1.1 如何理解软件的质量

1.1.2 提高软件质量的基本方法

1.1.3 “零缺陷”理念

1.2 细说软件质量属性

1.2.1 正确性

1.2.2 健壮性

1.2.3 可靠性

1.2.4 性能

1.2.5 易用性

1.2.6 清晰性

1.2.7 安全性

1.2.8 可扩展性

1.2.9 兼容性

1.2.10 可移植性

1.3 人们关注的不仅仅是质量

1.3.1 质量、生产率和成本之间的关系

1.3.2 软件过程改进的基本概念

1.4 高质量软件开发的基本方法

1.4.1 建立软件过程规范

1.4.2 复用

1.4.3 分而治之

1.4.4 优化与折中

1.4.5 技术评审

1.4.6 测试

1.4.7 质量保证

1.4.8 改错

1.5 关于软件开发的一些常识和思考

1.5.1 有最好的编程语言吗

1.5.2 编程是一门艺术吗

1.5.3 编程时应该多使用技巧吗

1.5.4 换更快的计算机还是换更快的算法

1.5.5 错误是否应该分等级

1.5.6 一些错误的观念

1.6 小结

第2章 编程语言发展简史

2.1 编程语言大事记

2.2 Ada的故事

2.3 C/C++发展简史

2.4 Borland与Microsoft之争

2.5 Java阵营与Microsoft的较量

2.6 小结

第3章 程序的基本概念

3.1 程序设计语言

3.2 语言实现

3.3 程序库

3.4 开发环境

3.5 程序的工作原理

3.6 良好的编程习惯

第4章 C++/C程序设计入门

4.1 C++/C程序的基本概念

4.1.1 启动函数main()

4.1.2 命令行参数

4.1.3 内部名称

4.1.4 连接规范

4.1.5 变量及其初始化

4.1.6 C Runtime Library

4.1.7 编译时和运行时的不同

4.1.8 编译单元和独立编译技术

4.2 基本数据类型和内存映像

4.3 类型转换

4.3.1 隐式转换

4.3.2 强制转换

4.4 标识符

4.5 转义序列

4.6 运算符

4.7 表达式

4.8 基本控制结构

4.9 选择（判断）结构

4.9.1 布尔变量与零值比较

4.9.2 整型变量与零值比较

4.9.3 浮点变量与零值比较

4.9.4 指针变量与零值比较

4.9.5 对if语句的补充说明

4.9.6 switch结构

4.10 循环（重复）结构

4.10.1 for语句的循环控制变量

4.10.2 循环语句的效率

4.11 结构化程序设计原理

4.12 goto/continue/break语句

4.13 示例

第5章 C++/C常量

5.1 认识常量

5.1.1 字面常量

5.1.2 符号常量

5.1.3 契约性常量

5.1.4 枚举常量

5.2 正确定义符号常量

5.3 const与#define的比较

5.4 类中的常量

5.5 实际应用中如何定义常量

第6章 C++/C函数设计基础

6.1 认识函数

6.2 函数原型和定义

6.3 函数调用方式

6.4 认识函数堆栈

6.5 函数调用规范

6.6 函数连接规范

6.7 参数传递规则

6.8 返回值的规则

6.9 函数内部实现的规则

6.10 存储类型及作用域规则

6.10.1 存储类型

6.10.2 作用域规则

6.10.3 连接类型

6.11 递归函数

6.12 使用断言

6.13 使用const提高函数的健壮性

6.13.1 用const修饰函数的参数

6.13.2 用const修饰函数的返回值

第7章 C++/C指针、数组和字符串

7.1 指针

7.1.1 指针的本质

7.1.2 指针的类型及其支持的运算

7.1.3 指针传递

7.2 数组

7.2.1 数组的本质

7.2.2 二维数组

7.2.3 数组传递

7.2.4 动态创建、初始化和删除数组的方法

7.3 字符数组、字符指针和字符串

7.3.1 字符数组、字符串和'\0'的关系

7.3.2 字符指针的误区

7.3.3 字符串拷贝和比较

7.4 函数指针

7.5 引用和指针的比较

第8章 C++/C高级数据类型

8.1 结构（struct）

8.1.1 关键字struct与class的困惑

8.1.2 使用struct

8.1.3 位域

8.1.4 成员对齐

8.2 联合（Union）

8.3 枚举（Enum）

8.4 文件

第9章 C++/C编译预处理

9.1 文件包含

9.1.1 内部包含卫哨和外部包含卫哨

9.1.2 头文件包含的合理顺序

9.2 宏定义

9.3 条件编译

9.3.1 #if、#elif和#else

9.3.2 #ifdef 和 #ifndef

9.4 #error

9.5 #pragma

9.6 #和##运算符

9.7 预定义符号常量

第10章 C++/C文件结构和程序版式

10.1 程序文件的目录结构

10.2 文件的结构

10.2.1 头文件的用途和结构

10.2.2 版权和版本信息

10.2.3 源文件结构

10.3 代码的版式

10.3.1 适当的空行

10.3.2 代码行及行内空格

10.3.3 长行拆分

10.3.4 对齐与缩进

10.3.5 修饰符的位置

10.3.6 注释风格

10.3.7 ADT/UDT版式

第11章 C++/C应用程序命名规则

11.1 共性规则

11.2 简单的Windows应用程序命名

第12章 C++面向对象程序设计方法概述

12.1 漫谈面向对象

12.2 对象的概念

12.3 信息隐藏与类的封装

12.4 类的继承特性

12.5 类的组合特性

12.6 动态特性

12.6.1 虚函数

12.6.2 抽象基类

12.6.3 动态绑定

12.6.4 运行时多态

12.6.5 多态数组

12.7 C++对象模型

12.7.1 对象的内存映像

12.7.2 隐含成员

12.7.3 C++编译器如何处理成员函数

12.7.4 C++编译器如何处理静态成员

12.8 小结

第13章 对象的初始化、拷贝和析构

13.1 构造函数与析构函数的起源

13.2 为什么需要构造函数和析构函数

13.3 构造函数的成员初始化列表

13.4 对象的构造和析构次序

13.5 构造函数和析构函数的调用时机

13.6 构造函数和赋值函数的重载

13.7 示例：类String的构造函数和析构函数

13.8 何时应该定义拷贝构造函数和拷贝赋值函数

13.9 示例：类String的拷贝构造函数和拷贝赋值函数

13.10 用偷懒的办法处理拷贝构造函数和 拷贝赋值函数

13.11 如何实现派生类的基本函数

第14章 C++函数的高级特性

14.1 函数重载的概念

14.1.1 重载的起源

14.1.2 重载是如何实现的

14.1.3 小心隐式类型转换导致重载函数产生二义性

14.2 成员函数的重载、覆盖与隐藏

14.2.1 重载与覆盖

14.2.2 令人迷惑的隐藏规则

14.2.3 摆脱隐藏

14.3 参数的默认值

14.4 运算符重载

14.4.1 基本概念

14.4.2 运算符重载的特殊性

14.4.3 不能重载的运算符

14.4.4 重载++和--

14.5 函数内联

14.5.1 用函数内联取代宏

14.5.2 内联函数的编程风格

14.5.3 慎用内联

14.6 类型转换函数

14.7 const成员函数

第15章 C++异常处理和RTTI

15.1 为什么要使用异常处理

15.2 C++异常处理

15.2.1 异常处理的原理

15.2.2 异常类型和异常对象

15.2.3 异常处理的语法结构

15.2.4 异常的类型匹配规则

15.2.5 异常说明及其冲突

15.2.6 当异常抛出时局部对象如何释放

15.2.7 对象构造和析构期间的异常

15.2.8 如何使用好异常处理技术

15.2.9 C++的标准异常

15.3 虚函数面临的难题

15.4 RTTI及其构成

15.4.1 起源

15.4.2 typeid运算符

15.4.3 dynamic_cast<>运算符

15.4.4 RTTI的魅力与代价

第16章 内存管理

16.1 内存分配方式

16.2 常见的内存错误及其对策

16.3 指针参数是如何传递内存的

16.4 free和delete把指针怎么啦

16.5 动态内存会被自动释放吗

16.6 杜绝“野指针”

16.7 有了malloc/free为什么还要new/delete

16.8 malloc/free的使用要点

16.9 new有3种使用方式

16.9.1 plain new/delete

16.9.2 nothrow new/delete

16.9.3 placement new/delete

16.10 new/delete的使用要点

16.11 内存耗尽怎么办

16.12 用对象模拟指针

16.13 泛型指针auto_ptr

16.14 带有引用计数的智能指针

16.15 智能指针作为容器元素

第17章 学习和使用STL

17.1 STL简介

17.2 STL头文件的分布

17.2.1 容器类

17.2.2 泛型算法

17.2.3 迭代器

17.2.4 数学运算库

17.2.5 通用工具

17.2.6 其他头文件

17.3 容器设计原理

17.3.1 内存映像

17.3.2 存储方式和访问方式

17.3.3 顺序容器和关联式容器的比较

17.3.4 如何遍历容器

17.3.5 存储空间重分配问题

17.3.6 什么样的对象才能作为STL容器的元素

17.4 迭代器

17.4.1 迭代器的本质

17.4.2 迭代器失效及其危险性

17.4.3 如何在遍历容器的过程中正确删除元素

17.5 存储分配器

17.6 适配器

17.7 泛型算法

17.8 一些特殊的容器

17.8.1 string类

17.8.2 bitset并非set

17.8.3 节省存储空间的vector

17.8.4 空容器

17.9 STL容器特征总结

17.10 STL使用心得

附录A C++/C试题

附录B C++/C试题答案与评分标准

附录C 大学十年

附录D 《大学十年》后记

附录E 术语与缩写解释

高质量程序设计指南 C++/C语言（第3版）（修订版） 精彩文摘

1.5.3编程时应该多使用技巧吗

作者的观点：就软件开发而言，技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。若在程序中使用太多的技巧，可能会留下错误隐患，别人也难以理解。一个局部的优点对整个系统而言是微小的，而一个错误则可能对整个系统是致命的。我建议用自然的方式编程，不要滥用技巧。我们有时的确不知道自己的得意之举究竟是锦上添花，还是画蛇添足。就像蒸出一笼馒头，在上面插一朵鲜花，本想弄点诗情画意，却让人误以为那是一堆热气腾腾的牛粪。

小时候读的《狼三则》故事启示我们，失败的技巧被讽刺为“伎俩”。当我们编程时无法判断用的是技巧还是伎俩的情况下，那就少用。《卖油翁》的故事又告诉我们“熟能生巧”，表明技巧是自然而然产生的，不是卖弄出来的。

1.5.4换更快的计算机还是换更快的算法

如果软件运行较慢，是换一台更快的计算机，还是设计一种更快的算法?

作者的观点：如果开发软件的目的是为了学习或是研究，那么应该设计一种更快的算法。如果该软件已经用于商业，则需谨慎考虑。若换一台更快的计算机能解决问题，则是最快的解决方案。改进算法虽然可以从根本上提高软件的运行速度，但可能引入错误并延误进度。

技术狂毫无疑问会选择后者，因为他们觉得放弃任何可以优化的机会就等于犯罪。类似的争议还有：是买现成的程序，还是彻底由自己开发?技术人员和商业人士常常会有不同的决策。

1.5.5错误是否应该分等级

微软的一些开发小组将错误分成以下4个等级（Cusumano，P354～P355）。

一级严重：错误导致软件崩溃。

二级严重：错误导致一个特性不能运行并且没有替代方案。

三级严重：错误导致一个特性不能运行但有替代方案。

四级严重：错误是表面化的或是微小的。

作者的观点：将错误分等级的好处是便于统计分析，仅此而已。但上述分类带有较重的技术倾向，并不是普遍适用的。假设某个财务软件有两个错误：错误A使该软件死掉，错误B导致工资计算错误。按上述分类，错误A属一级严重，错误B属二级严重。但事实上B要比A严重。工资算多了或者算少了，将会使老板或员工遭受经济损失。而错误A只是使操作员感到厌烦，并没有造成经济损失。再例如航空软件操作手册写错了，按上述分类则属四级严重，但这种错误可能导致机毁人亡，难道还算微小吗?
开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。只有这样才能少犯错误。