您对“大规模 C++ 软件设计”的看法 [关闭]

Posted 2023-03-08

【中文标题】您对“大规模 C++ 软件设计”的看法 [关闭]

【英文标题】：Your thoughts on "Large Scale C++ Software Design" [closed]

【发布时间】：2010-12-24 01:34:27

【问题描述】：

阅读 reviews at Amazon 和 ACCU 表明 John Lakos 的书大型 C++ 软件设计可能是模块化的罗塞塔石碑。

同时，这本书似乎真的很稀有：没有多少人读过它，也没有盗版电子版在流传。

那么，你怎么看？

【问题讨论】：

没有读过，所以我只会评论.. 但是我们很多人看我们的项目，可能认为它们是“小规模”而不是“大规模”。除非您遇到 Firefox、Windows NT 或 Linux 内核之类的东西，否则人们不会开始大规模思考。

... 这确实是您阅读 Lakos 的规模。多亏了摩尔，他的大规模不是今天的大规模。

CAD 软件经常运行到数百万行。虽然像 Excel 这样的大型桌面应用程序同样复杂（如果不是更复杂的话），但我认为贬低代码库的规模是不公平的。他的介绍提到了价值数千人年开发工作的软件。我曾经工作过的最大的系统有数百个，并且（当时）是在大洋洲建造的最大的 J2EE 应用程序。 Lakos 正在研究比这大一个数量级的系统。

@George Stocker：感谢编辑（尤其是罗塞塔石碑的比喻）。

@George Stocker：希望问题的结尾不要读作“......那么，盗版电子副本在哪里？” :)))

【参考方案1】：

它有点过时了（实际上它在写的时候已经过时了）。如果我没记错的话，其中很多是关于减少你现在可能会用模板来做的依赖关系。

虽然这可能是在大型项目中学习的经验之一，但您通常不会使用尖端功能和工具。

【讨论】：

如果有一件事我不会做，那就是使用模板来降低我的物理依赖关系，或者希望它会减少构建时间。您真的不希望在具有当前编译器的大型项目中使用大量模板 - 它们会减慢很多速度，因为每次使用都需要访问完整的模板。另一方面，我认为在大型项目中应该大量使用 pimpl 成语。

【参考方案2】：

我很久以前就读过它，但我记得从中得到了很多；虽然正如 MadKeithV 指出的那样，那可能只是我当时知道的少；）

当然，从“我如何减少构建所需的时间”的角度来看，它有很多有用的东西，尤其是在减少编译时间依赖方面，尽管考虑到有多少它可能不再相关，甚至可能不再相关这些天都在使用模板。

不，你也不能得到我的副本 :)

【参考方案3】：

是的，在某些方面，这本书有点过时了，其中一些是特定于 C++ 的。尽管如此，它还是为处理大型程序中的复杂性和耦合提供了许多有用的建议，而且他的大部分建议适用于任何面向对象的语言。我也发现它非常可读。

如果您能找到一份副本，我相信您会发现它值得一读。它在我的十大编程书籍列表中。

【参考方案4】：

我认为这本书在 1990 年代后期是一本不错的读物。那时它已经过时了，现在与 1950 年代的电话簿一样重要。

我与 Lakos 合作了几年，他试图实施这些想法。我也有我用大约 2000 个源文件构建的现代 C++ 项目——规模足够大，从那以后我又构建了几个。使用诸如冰淇淋之类的程序可以通过并行分布式构建轻松减少构建时间。每个编译器都会缓存打开的标头——只有通过做一些真正令人发指的事情，任何现代构建工具（如 scons）才能扩展到数千个翻译单元，而无需做任何真正特别的事情，构建时间（包括测试）需要几分钟才能完成。

将您的库接口限制为一些“词汇类型”（与 OO 概念的含义不同，他的意思是只使用 Int、float、string、char 和其他一些我不记得的）非常糟糕建议扩展任何东西。您的构建将寻找类型不匹配，您不希望在运行时这样做只是为了更容易编写 make 文件。

这就是本书的主要内容——我如何编写 C++ 以便它与 1993 年的工具一起使用？此外，这本书描述的 Mentor Graphic 项目在所有人看来都是一场灾难。甚至这本书本身也暗示了这一点。

Large Scale C++ 以源代码形式提供——这些是“物理依赖项”，而不是链接库（本书从未提及其他更重要的依赖项，如数据库、套接字、处理器架构、等等）。

这本书充满了听起来不错的想法，但还有很多更好的方法可以在实践中扩大规模。如果您想研究大型 C++ 库，请查看 Boost 或 Xerces 看看他们做了什么。他们实际上是在实施大型项目，而不是在撰写有关它们的文章。

【讨论】：

非常感谢你的洞察力（有时失败想法的故事对他们来说比其他任何东西都更有价值——至少当想法本身有明确的价值时；有趣的是，这类似于我的故事大卫帕纳斯在他的书中讲述了他和他的团队曾经试图将他的想法应用到的航空电子软件——因为它实际上是一个失败，但它应该在教科书中获得光荣的地位）:)

但是 (informit.com/articles/article.aspx?p=2088514)：Large-Scale C++, Volume I: Process and Architecture by John Lakos (2014) ISBN-13: 9780201717068 所以这本新书不是谣言 :)

我记得 10 年前读过那本书的草稿。如果您阅读 github 上的 BDE 标准文档，您仍然会发现多余的包含保护，即“组件”实际上只是一对 .h/.cpp 文件的概念。还有很多关于缩进和文档格式的废话。我期望本书中缺少的是扩展软件的两个关键项目：部署和集成测试。

【参考方案5】：

Lakos 曾为制作 EDA 软件的 Mentor Graphics 工作。他参与了用 C++ 构建 EDA 软件，他们希望有效地使用 C++（“开销不超过 C 代码的 5%”），并整理出如何在早期工作站上构建软件，而这些软件确实需要很长时间才能编译大型 C++ 应用程序。

这本书读起来很不错——它讨论了各种各样的主题，而 Lakos 确实知道他的东西。他确实来自必须从 C++ 编译器中获取高效代码的背景，以及如何设置 C++ 程序以使其可维护并合理快速地编译和链接。

我认为 Lakos 有很多见解，我建议您阅读它。然而，在模板等功能被广泛使用之前，它是“传统的”C++。我的副本不出售；^)

【讨论】：

@"我的副本不卖" 我就知道！ :)

C++ 不再是本月的热门话题，因此您可能可以很便宜地获得二手副本。亚马逊市场是你的朋友 ;^)

以下是 EDA 内部人士对 Mentor's Falcon 的一些看法 chipdesignmag.com/payne/2009/11/17/…

【参考方案6】：

有趣的是，"More C++ Gems" 包含 Lakos 书​​的缩短版（到 88（！）页），也可以浏览（完全，我相信，因为它属于书的前半部分）online at Google books .

所以，让所有感兴趣的人享受吧:)

【参考方案7】：

我读过它，并认为它是一本关于大型 C++ 项目的一些实际问题的非常有用的书。如果您已经阅读了很多有关 C++ 的内容，并且对物理设计及其含义有所了解，那么您可能不会在本书中找到那么多非常“新”的内容。

另一方面，如果您的构建需要 4 个小时，并且您不知道如何缩减它，请获取一份副本，阅读它，然后将其全部纳入。

您将很快开始编写物理上更好的代码。

[编辑] 如果您想从某个地方开始，但无法立即拿到这本书，我发现 Games From Within series on physical structure 即使在阅读了大规模 C++ 设计之后也很有用。

【参考方案8】：

这是一本优秀的书，从历史的角度来看也是一本重要的书。

请注意，要实施本书中描述的实践，您需要在团队中遵守纪律并达成一致。这里有几点需要注意：

Lakos 对他所谓的“组件”和“包”有精确的定义。这些是大规模设计的关键。但是，它们需要遵守有关如何命名源文件和头文件以及包含它们的顺序的约定。遗憾的是，大多数人（包括引用 Lakos 的人）很少遵循这些约定。

这本书全都是关于 C++ 的，但这些概念的适用范围更广。然而，由于 C++ 是一门复杂的语言，本书的大部分内容是教你如何有效地使用 C++。如果你能克服这一点，即使你使用其他语言，你也会发现它实际上很有用。

一些规定，例如关于“名称空间”的使用，现在可能被认为是有争议的。许多人认为在 C++ 中应该以有限的方式使用名称空间。

【参考方案9】：

John Lakos 的“Large-Scale C++ Software Design”是一个发人深省（但通常被忽视）的瑰宝吗？

Yes.

【讨论】：

他们不是也有一篇关于主要答案的文章吗？:)