大规模C++程序设计
点击看大图基本信息
内容简介回到顶部↑
本书是专为有经验的C++软件的开发者、系统设计师、软件质量保证人员编写的。适合从事大型软件开发工作（如数据库、操作系统、编译程序和框架）的人员阅读。
本书将高层设计概念与特定的C++编程细节结合起来，满足下面两个要求：
1、一本面向对象设计的书，尤其侧重于C++编程语言实现方面。
2、一本c++程序设计的书，描述如何使用C++编程语言来开发非常大型的系统。
本书将高层设计概念与特定的C++编程细节结合起来，满足下面两个要求：
1、一本面向对象设计的书，尤其侧重于C++编程语言实现方面。
2、一本c++程序设计的书，描述如何使用C++编程语言来开发非常大型的系统。
目录回到顶部↑
第0章 引言
0.1 从c到c++
0.2 用c++开发大型项目
0.3 重用
0.4 质量
0.5 软件开发工具
0.6 小结
第1部分 基础知识
第1章 预备知识
1.1 多文件c++程序
l.2 typedef（类型别名）声明
1.3 assert语句
1.4 有关风格的一些问题
1.5 迭代器
1.6 逻辑设计符号
1.7 继承与分层
0.1 从c到c++
0.2 用c++开发大型项目
0.3 重用
0.4 质量
0.5 软件开发工具
0.6 小结
第1部分 基础知识
第1章 预备知识
1.1 多文件c++程序
l.2 typedef（类型别名）声明
1.3 assert语句
1.4 有关风格的一些问题
1.5 迭代器
1.6 逻辑设计符号
1.7 继承与分层
相关资源回到顶部↑
· 【推荐】众多高校学子口口相传，他们共同的选择--华清远见嵌入式学院(嵌入式Linux就业课程、3G手机开发就业课程，通过入学测试即签100%就业协议，4个月集中实训，世界500强企业成功就业保障！！！)· 【亚嵌教育 嵌入式培训专家】(嵌入式培训，嵌入式Linux培训，ARM培训,Linux培训，3G培训，Android培训，WINCE培训，DSP培训，FPGA培训，嵌入式就业培训)
· 程序员的7种武器(正则表达式、编程语言、数据库、算法、软件调试、开发环境)
· C/C++ 经典著作(《C专家编程》《C++ Templates中文版》《C和指针 》《C陷阱与缺陷》《C++沉思录》)
评论交流
共有61人开贴评论 123人参与评论 49人参与打分 查看
评价等级：
发表于：2007-8-5 22:50:00
其实lakos这本书讲述的问题很简单，就是包设计原则，这些原则跟OCP、DIP一样，在敏捷软件开发中都论述过，当然不是每个人都看懂了这些后面的原则；
但是，在C++语言中，你找不到包这个抽象概念所对应的东西，而且C++的链接过程有太多初学者没有弄明白的内容，而恰恰是这些内容破坏了文件的物理组织，加上大多数未经训练的软件开发者都没有将文件、目录当作包组织的概念，造成了大多数项目工程中代码组织的混乱，也许他们是好运的，没有遇上lakos它们那样，一个版本要编译一周的厄运；
其实lakos是想在这本书上提出一套规范，大家按照这套规范来设计具有良好物理组织的大规模C++软件，这曾经是老B为了兼容C的同时赋予自由散漫C++程序员的自由，但这些自由却成了C++程序员的噩梦；
稍后在C++基础之上改进的语言中，无不悄悄的加上了物理设计的限制，例如java中：
1、一个类只能放在一个源文件中，而不能像C++那样区分.h和.cpp，要是.h和.cpp的文件名还不一样怎么办，天哪。。。
2、一个.java只能有一个public class，这样的要求强制开发者去严肃对待源文件的物理组织，这个物理单元提供的接口是什么？哪些作为实现？；
3、没有了extern这样的链接指示符，避免了C++中两个毫无关系的obj，莫名的在链接时刻产生了依赖，java中一个import关键字的轻易搞定的依赖声明，在C++中lakos却要先保证.h/.cpp同名，然后还要禁止掉extern声明，他的idep工具才能正常工作，要是再遇到#include后面的大小写有区别。。。idep也不干活了。。。
整本书下来,lakos除了苦口婆心的告诉大家依赖危害性，如何建立起一套规范从物理上来改善依赖，如何从逻辑设计上避免引入依赖，最后的最后还给了一套用来分析依赖、度量依赖和检测循环依赖的idep工具集。
可惜的是，如此工程界大师的作品，却没人关注……
（补充：词汇翻译上有些小地方感觉别扭，本文只评原书）
但是，在C++语言中，你找不到包这个抽象概念所对应的东西，而且C++的链接过程有太多初学者没有弄明白的内容，而恰恰是这些内容破坏了文件的物理组织，加上大多数未经训练的软件开发者都没有将文件、目录当作包组织的概念，造成了大多数项目工程中代码组织的混乱，也许他们是好运的，没有遇上lakos它们那样，一个版本要编译一周的厄运；
其实lakos是想在这本书上提出一套规范，大家按照这套规范来设计具有良好物理组织的大规模C++软件，这曾经是老B为了兼容C的同时赋予自由散漫C++程序员的自由，但这些自由却成了C++程序员的噩梦；
稍后在C++基础之上改进的语言中，无不悄悄的加上了物理设计的限制，例如java中：
1、一个类只能放在一个源文件中，而不能像C++那样区分.h和.cpp，要是.h和.cpp的文件名还不一样怎么办，天哪。。。
2、一个.java只能有一个public class，这样的要求强制开发者去严肃对待源文件的物理组织，这个物理单元提供的接口是什么？哪些作为实现？；
3、没有了extern这样的链接指示符，避免了C++中两个毫无关系的obj，莫名的在链接时刻产生了依赖，java中一个import关键字的轻易搞定的依赖声明，在C++中lakos却要先保证.h/.cpp同名，然后还要禁止掉extern声明，他的idep工具才能正常工作，要是再遇到#include后面的大小写有区别。。。idep也不干活了。。。
整本书下来,lakos除了苦口婆心的告诉大家依赖危害性，如何建立起一套规范从物理上来改善依赖，如何从逻辑设计上避免引入依赖，最后的最后还给了一套用来分析依赖、度量依赖和检测循环依赖的idep工具集。
可惜的是，如此工程界大师的作品，却没人关注……
（补充：词汇翻译上有些小地方感觉别扭，本文只评原书）
)
加载中...| 我要写评论 |
| 查看所有评论交流(共61条) |
