您对“大型C ++软件devise”的看法
阅读亚马逊和ACCU的评论表明，John Lakos的书“ 大规模C ++软件devise”可能是模块化的Rosetta Stone。
与此同时，这本书似乎是非常罕见的：没有多less人读过它，没有海盗电子副本在四处stream动。
所以你怎么看？
[由于这是谷歌search书名第三，留下我的投票重新开放，这将是一个可惜的是，在这里放弃所有有用的讨论（我一直认为这是适合它的地方）。]
我读过它，并认为它是一个关于大型C ++项目的一些实际问题的非常有用的书。 如果您已经阅读了很多关于C ++的知识，并了解了一些关于物理devise及其含义的知识，那么本书中可能不会发现那些非常“新”的东西。
另一方面，如果你的构build需要4个小时，而你又不知道如何削减它，那就抄一份，阅读一下，
你会开始写很快的物理更好的代码。
[编辑]如果你想从某个地方开始，并且不能马上拿到书，我甚至在阅读大规模C ++devise之后，发现了“ 从内部游戏”系列的物理结构 。
有趣的是， “更多的C ++gem”包含了一个缩写（至88页）版本的Lakos书，也可以在Google图书在线浏览（完全相信，因为它属于本书的前半部分） 。
所以，请大家感兴趣:)
Lakos曾经为制造EDA软件的Mentor Graphics工作。 他参与了用C ++构buildEDA软件，他们希望高效地使用C ++（“比C代码less5％的开销”），并在早期的工作站上构build软件，这需要花费很长时间来编译大型的C ++应用程序。
这本书是相当不错的阅读 – 它讨论了各种各样的话题，拉科斯真的知道他的东西。 他的确来自于必须从C ++编译器中获取高效代码的背景，以及如何设置一个C ++程序，使其可维护，编译和链接合理快速。
我认为拉科斯有很多见解，我build议你阅读。 然而，从诸如模板之类的function被广泛使用之前，它就是“传统的C ++”。 我的副本不出售; ^）
我认为这本书在20世纪90年代后期是一个很好的回顾。 现在已经过时了，现在和20世纪50年代的电话簿一样重要。
我和拉科斯一起工作了好几年，试图实现这些想法。 我也有我的现代C ++项目，我build立了约2000个源文件 – 足够大的规模，我已经build立了几个。 并行分布式构build，使用冰淇淋等程序，可轻松缩短构build时间。 每个编译器都会caching已打开的头文件 – 只有通过做一些非常令人发指的现代构build工具（如scons）才能扩展到数千个翻译单元，而不需要做任何特别的事情，包括testing在内的构build时间需要几分钟的时间。
将你的库接口限制为几个“词汇types”（与OO概念不一样，他的意思是使用Int，float，string，char和其他一些我不记得的东西）是极其糟糕的build议任何东西。 你的构build会寻找一个types不匹配，你不想在运行时只是为了更容易写一个make文件。
这主要是本书的要点 – 我如何编写C ++才能使用1993年的工具？ 另外，这本书所描述的Mentor Graphic项目是所有账户的灾难。 即使这本书也暗示了这一点。
大规模的C ++是以源代码forms交付的 – 这些是“物理依赖性”，而不是链接库（而书从未提及其他更重要的依赖关系，如数据库，套接字，处理器体系结构等）。
这本书充满了听起来不错的想法，但是在实践中还有更好的方法来扩大规模。 如果你想学习大型C ++库，看看Boost或者Xerces ，看看他们做了什么。 他们真的在实施大型项目，而不是写关于它们的东西。
John Lakos的“大规模C ++软件devise”是一个引人注目（但通常被忽略）的gem吗？
是的 。
这是有点过时了（实际上它已经过时了）。
IIRC ，很多是关于减less你现在可能使用模板的依赖关系。
虽然这可能是大规模项目学习的教训之一，但通常不会使用尖端的function和工具。
这是一本很好的书，从历史的angular度来看是一本重要的书。
请注意，要实施本书中所描述的实践，您需要在团队中有相当的纪律和协议。 这里有一些事情要注意：
-
Lakos对他所谓的“组件”和“包装”有精确的定义。 这些是大规模devise的关键。 但是，它们需要遵守约定，以便如何命名源文件和头文件以及它们的包含顺序。 很遗憾，大多数人（包括引用拉科斯的人）很less遵循这些惯例。
-
这本书是关于C ++的，但这些概念更为广泛适用。 但是，因为C ++是如此复杂的语言，本书的很大一部分是教你如何有效地使用C ++。 如果你可以通过这一点，即使你使用其他语言，你也可以发现它很有用。
-
一些处方，比如使用“名字空间”，现在可能被认为是有争议的。 许多人认为应该在C ++中以有限的方式使用名称空间。
是的，在某些方面，这本书有点过时了，其中一些是C ++特有的。 尽pipe如此，它在处理大型程序中的复杂性和耦合方面提供了许多有用的build议，而且他的build议大部分适用于任何面向对象的语言。 我也发现它很可读。
如果你能find一份，我相信你会发现它值得一读。 这是我编程书籍的前十名单。
我很久以前就读过这本书，但是我记得它从中得到了很多。 尽pipe正如MadKeithV所指出的那样，那可能就是我所知道的那样;）
当然，从“如何减less构build需要多长时间”的angular度来看，它有很多有用的东西，特别是在减less编译时间依赖性的同时，虽然可能有些依赖不再相关，甚至是可能的，因为使用了多less模板这些天。
不，你不能有我的副本:)
我想添加到所有这些答案，它只对C有用，因为这种语言有头地狱的问题。 一些build议今天是相当无用的，比如当你更好地使用一些预编译的头文件（每个包一个）的时候，像编译器或者头文件组合一样，包含守护进程。
如果你问我是否值得购买，那么我回答：只有你是C / C ++开发的初学者。 目前的C ++世界（模板和模板，我已经提到模板）的问题不符合。
但我只是看了一遍这本书。 它给了我美好的回忆，并再次告诉我为什么这个语言是完全错误的，需要被replace。
