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

Your thoughts on "Large Scale C++ Software Design"

提问by mlvljr

Reading the reviews at Amazonand ACCUsuggests that John Lakos' book, Large-Scale C++ Software Designmay be the Rosetta Stone for modularization.

阅读Amazon和ACCU的评论表明，John Lakos 的书《大规模 C++ 软件设计》可能是模块化的罗塞塔石碑。

At the same time, the book seems to be really rare: not many have ever read it, and no pirate electronic copies are floating around.

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

So, what do you think?

所以你怎么看？

采纳答案by Joris Timmermans

I've read it, and consider it a very useful book on some practical issues with large C++ projects. If you have already read a lot about C++, and know a bit about physical design and its implications, you may not find that much which is terribly "new" in this book.

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

On the other hand, if your build takes 4 hours, and you don't know how to whittle it down, get a copy, read it, and take it all in.

另一方面，如果您的构建需要 4 个小时，而您不知道如何减少它，请获取副本，阅读它，然后将其全部吸收。

You'll start writing physically better code quite quickly.

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

[Edit] If you want to start somewhere, and can't immediately get a hold of the book, I found the Games From Within series on physical structureuseful even after reading Large Scale C++ design.

[编辑] 如果你想从某个地方开始，并且不能立即拿到这本书，我发现即使在阅读了大规模 C++ 设计之后，关于物理结构的游戏从内部系列也很有用。

回答by mlvljr

Interestingly, "More C++ Gems"contains a shortened (to 88(!) pages) version of Lakos' book, which can also be browsed (fully, I believe, as it belongs to the first half of the book) online at Google books.

有趣的是，“More C++ Gems”包含 Lakos 书​​的缩短版（88（！）页），也可以在 Google 图书上在线浏览（我相信它属于本书的前半部分）.

So, enjoy everyone interested:)

所以，享受每个感兴趣的人:)

回答by ConcernedOfTunbridgeWells

Lakos used to work for Mentor Graphics, who makes EDA software. He was involved in building EDA software in C++, where they wanted to use C++ efficiently ('no more than 5% overhead over C code') and sort out how to build software on early workstations that really would take a long time to compile a large C++ application.

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

The book is quite a good read - it discusses a wide variety of topics, and Lakos really did know his stuff. He really comes from a background of having to get efficient code out of a C++ compiler, as well as how to set up a C++ program so it is maintainable and compiles and links reasonably quickly.

这本书非常值得一读——它讨论了各种各样的主题，而且 Lakos 确实知道他的东西。他确实来自必须从 C++ 编译器中获取高效代码的背景，以及如何设置 C++ 程序以使其可维护、编译和链接相当快。

I think that Lakos has a lot of insight, and I would recommend that you read it. However, it is 'trad' C++ from a time before features like templates were widely available. My copy is not for sale ;^)

我认为 Lakos 有很多见解，我建议您阅读它。但是，在模板等功能广泛可用之前，它是“传统”C++。我的副本不卖;^)

回答by Lance Diduck

I thought the book was a good read back in the late 1990s. It was out of date back then, now about as relevant as telephone book from the 1950s.

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

I worked with Lakos for several years where he tried to implement these ideas. I also had my modern C++ project I built of about 2000 source files-- large scale enough, and I've built a few more since. Build times are easily reduced by parallel distributed builds, using programs like icecream. Every complier will cache opened headers-- only by doing something really outrageous any modern build tool like scons will scale to thousands of translation units without doing anything really special, with build times, including tests, takes a couple minutes from clean.

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

Limiting your libraries interface to a few "vocabulary types" (not the same sence as the OO concept, he means just use Int, float, string, char, and a couple of other I don't recall) is extremely poor advice to scale anything. Your build is going to be looking for a type mismatch, you don't want this at runtime just to make it easier to write a make file.

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

And that's largely the gist of the book-- how do I write C++ in order that it works with tools from 1993? Additionally, the Mentor Graphic project the book describes was a disaster from all accounts. Even the book itself alludes to that.

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

Large Scale C++is delivered in source code form-- these are the "physical dependencies," not link libraries (and the book never mentions other more important dependencies like databases, sockets, processor architecture, etc.).

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

The book is full of ideas that sound good, but there are much better ways to scale up in practice. If you want to study large C++ libraries, take a look at Boostor Xercesand see what they did. They really are implementing large projects, not writing about them.

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

回答by Martin Beckett

It's a little out of date (in fact it was out of date when it was written). If I recall correctly, a lot of it was about reducing dependencies which you would probably do now with templates.

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

Although that's probably one of the lessons to learn on large scale projects, you aren't usually using cutting-edge features and tools.

尽管这可能是大型项目中要学习的课程之一，但您通常不会使用尖端的功能和工具。

回答by Stephen C. Steel

Yes, in some ways, the book is a little dated and some of it is C++ specific. Nonetheless, it offers a lot of useful advice about dealing with complexity and coupling in large programs, and most of his advice applies to any object-oriented language. I also found it very readable.

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

If you can track down a copy, I'm sure you'll find it worth reading. It's in my top ten list of programming books.

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

回答by Rob Grant

Is “Large-Scale C++ Software Design” by John Lakos a mind-provoking (but usually overlooked) gem?

John Lakos 的“大规模 C++ 软件设计”是一个发人深省（但通常被忽视）的宝石吗？

Yes.

是的。

回答by Neeraj Sangal

It is an excellent book and an important one from a historical point of view.

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

Note that to implement the practices described in the book, you need considerable discipline and agreement within the team. Here are a few things to note:

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

1. Lakos has precise definitions for what he calls "components" and "packages". These are key for large scale design. However, they require adherence to conventions for how source and header files are named and the sequence in which they are included. It is a shame that most people (including those who quote Lakos) rarely follow these conventions.

2. The book is all about C++ but the concepts are more widely applicable. However, because C++ is such a complex language, a large part of the book is teaching you how to use C++ effectively. If you can get past that, you can actually find it useful even if you use other languages.

3. Some of the prescriptions such as on the use of "name spaces" maybe considered controversial now. Many believe that name spaces should be used in a limited way in C++.

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

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

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

回答by Len Holgate

I read it a long time ago, but I remember getting quite a lot from it; though as MadKeithV points out, that may just have been that I knew less then ;)

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

Certainly from a "how do I reduce how long this takes to build" perspective it's has lots of useful stuff, especially around reducing compile time dependencies, though possibly some of it is no longer relevant, or even possible, given how much templates are used these days.

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

And no, you can't have my copy either :)

不，你也不能拥有我的副本:)