《大规模C++程序设计》书评

这本书适合。。。

本书的写作背景比较特殊，面向的人群比较狭窄。满足以下条件，你可以好好看看这本书：1 在某个软件中，必须使用C++作为软件开发的主要语言。2 软件的代码规模在100万以上。也就是要有一百万以上的C++代码。有这两个条件，你就会发现书里面说的很有用。如果你觉得看不懂，觉得书里介绍的问题和解决方案，莫名其妙，很想拍转，那说明这本书不适合你，你还是别看了。

在实践中用到了

这两天，要改动1个基础的类型。之前参考书里的方法画了package之间的依赖图。这下方便了，顺着依赖图指示，从依赖关系少的底层包开始重构编译，逐次推进到顶层包，最后整个程序一次性编译通过。package依赖图的好处还不止于此：1，可以指出相互依赖的不合理现象。2，新增模块时，考虑对依赖图的影响，便于保持程序结构的稳定和简洁。3，有了程序的全局俯视图，平时可以做更多的调整和优化。-------------------------------------------------------之前，和大侠讨论说，如果有工具能把依赖关系细化到模块就好了。这段实践下来，应该没有这个必要。有个包里的模块关系有点搞，特别为这个包画个模块依赖图就够了。

物理设计，在C++语言规范中被忽视的问题

其实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++

《蜗居》第24集3:30秒截图，有理由相信小贝是搞 C++ 的。 桌子上那本书放大看是《大规模Cpp程序设计》，为无数想为cpp献身的人士叹惜呀。搞了一辈子C++，结果老婆跟了宋思明。 这部电视剧深刻揭露了C++程序员的杯具性。相信这个重大发现将彻底粉碎那些少年们对程序员这个职业的向往，这个时代女生不会因为你写了一个搞笑程序而嫁给你。建议广大程序们建议你们周围的少男们看一下蜗居，如果他以你为荣，以后想当程序员。你可以告诉他，小贝就是程序员，然后告诉他宋思明是公务员。相信他就会重新考虑自己人生的选择了！！！！

这本书有参考价值，但已经没有用处！

因为有Java，所以现在大型系统会首选java。这本书所讲述的问题java都可以解决，并且很elegant!谁叫咱们已经进入2008年了呢。C++已经不在适合在大型系统中担当重要角色。仅此而以。

让我看完觉得相见恨晚的书

2006年的时候，我们开发了一个比较大的系统，开发参与人数有十几个（其实也不错），在但是的机器情况下，有时候只是动了一个头文件，会导致很长的编译时间，在这本书中可以找到答案。 《大规模C++程序设计》这本书是在2006年开发完一个相对较大的系统后读的一本书，当时看完，是少有的让我看完觉得相见恨晚的书，书分两部分内容，C++的逻辑设计和物理设计，这本书写的很早，95年左右，所以很多逻辑设计的原则在后来都在很多其它书中出现，但是物理设计其他书很少涉及，但是物理设计在大规模程序设计（平台开发）、接口设计和模块解耦上有非常重要的左右，现在很多概念上可能将之称为部署方式，随便提一句，翻译上有些是不怎么好，但基本上不影响阅读。推荐给每一位C++开发者。

今天用书中的方法重构了当前的项目结构

最近一直在看这本书，其中的一些方法之前也有用过，现在读来又有了新的收获，今天用了差不多一天的时间把当前的项目代码作了不小的重构，主要是从程序的物理结构方面，分层更明确，实现隐藏更彻底，编译耦合进一步降低，自己感觉还不错哦！

pragmatics

此书应该是属于pragmatics类型得书籍，还是很棒的这本书接近C语言接口和实现，可以说两本书讲的都是同一个主题，重点都在接口和实现两个主题上。虽然此书好像都在讲物理结构，恰好是作者想通过如此简单的概念去表达一个结构良好的程序设计。诚然此书是针对大型项目，但是对于小型项目也应该这样，良好的可维护性，可扩展性。。这本书的引申出来的理念值得每个程序员去掌握。

垃圾书

这本书真的很垃圾的，看完你就后悔。还说什么大规模C++的，其实连最基本的东西都没有说清楚。在指针如何使用方面根本没有说清楚。类那一块直接带过这本书真的很垃圾的，看完你就后悔。还说什么大规模C++的，其实连最基本的东西都没有说清楚。在指针如何使用方面根本没有说清楚。类那一块直接带过这本书真的很垃圾的，看完你就后悔。还说什么大规模C++的，其实连最基本的东西都没有说清楚。在指针如何使用方面根本没有说清楚。类那一块直接带过

无用的书？有用的书

这是一本定位很独特，甚至说有些奇怪的书。如果你想从该书中获得C++在实际使用中的经验或教训，你也许会失望。因为这本书里几乎都是十多行的小例子，而且这些例子并不比我们在TCPL、C++ Primer上看到的例子好多少。如果你想从该书中获得大型软件的设计经验，你也基本上会失望。因为这本书对系统设计的介绍，并没有高人一等之处。这本书，对大多数的人来说，是无用的。但是它真的一无是处吗？不是的。这本书的特色在于，它着眼于一个特殊而且狭窄的领域：C++大型系统的物理设计。它会告诉你如何组织你的文件，在.h和.cpp中分别应该写些什么，不该写些什么。它着眼于让你的系统更快的通过编译和链接，并更少的产生冗余代码和避免隐含的链接错误。并且使得“源文件”能够被尽可能方便的重用（对，你没看错，是源文件，不是类或接口之类）。我们也许曾经花过大量的时间去学习如何更好的抽象类和接口，如何使用设计模式做出漂亮的，兼顾扩展和内聚的组件关系。但是我们恐怕真的很少注意过源代码的组织、链接和编译的问题。因为我们以为那是编译器该做的事情。是的，在其它语言也许如此，但是在C/C++语言中，由于其特殊的底层操作方式，使得编译和链接问题并不像我们想象的那样轻松。稍不注意，我们就会实现出一个逻辑上漂亮，实际上运行缓慢，程序庞大的“四不象”来。这本书就让我们注意到了这一点，并且它还提出了不少有益的原则和建议。相信会对我们这些C++er们带来不小的帮助。这本书的适用层面非常狭窄，对于使用C++开发大系统的人，该书可以提供很大的帮助。对使用其它语言，或者仅用C++完成周边工作的人，该书的帮助不太大。此书的翻译并不完美，有些用词不够严谨，但应该说尚可。基本上可以体现原作者的意思。

书是好书

有位专家推荐过，看了两百多页后没再看下去。翻译得不好，不知道谁可以再重新翻译一下。实在不行只能看英文原版了。另，也许与扫描的PDF格式的阅读感受也有一定关系。

在3分和4分之间犹豫

还有20分钟下班，简单写几条。1，加强了内部依赖的概念。2，针对c++的特定语法，使得uml的应用比较叫明确了。3，对模块依赖性的定量计算方法，我很有一种冲动，以后新写程序时逐个模块的累加计算，随时发现依赖问题。4，印象比较深的是，哑元指针，在宿主对象里保存，还不产生依赖性，不错呀。下面说不满的地方：全书自己定了很多定义，结果把书搞得很厚。再加上翻译也不给力，看起来实在很吃力。看到后面越来越快，书到后面也越来越白。这书是从大侠那里借来的，相信物主也是这个过程。其实作者是来自企业界，完全可以写的简单点。不要这么搞得文绉绉的。真的大牛都在写条条杠杠，如effective 系列，都在写小薄书，如设计模式。自己搞一套也造成了很多的重复，如设计模式是不可回避的东西。最后说最大的收获：本书的一条优化是把data member指针化。于是我想，如果真的这样，data_member还有意义吗？是不是c++出了问题？还是用户出了问题？因为有这条启发，我在犹豫是否该给4分？