头文件中的多个类与每个类的单个头文件相对应

Question

无论出于何种原因，我们公司都有编码指南，声明：

Each class shall have it's own header and implementation file.

因此，如果我们编写了一个名为MyString的类，我们需要一个关联的 MyStringh.h 和 MyString.cxx 。

还有其他人这样做吗？有没有人看到任何编译性能影响？ 10000个文件中的5000个类的编译速度是否与2500个文件中的5000个类一样快？如果没有，差异是否明显？

[我们编写C ++并使用GCC 3.4.4作为我们的日常编译器]

Answer 1

这里的术语是翻译单元，你真的希望（如果可能的话）每个翻译单元有一个类，即每个.cpp文件一个类实现，相应的.h文件相同名。

通常更有效（从编译/链接）角度来做这种事情，特别是如果你正在做增量链接等事情。这个想法是，翻译单元是孤立的，当一个翻译单元改变时，你不必重建很多东西，就像你开始将许多抽象集中到一个翻译单元一样。

此外，您会发现通过文件名（“Myclass.cpp中的错误，第22行”）报告了许多错误/诊断，如果文件和类之间存在一对一的对应关系，则会有所帮助。 （或者我想你可以把它称为2对1对应）。

Answer 2

Answer 3

我们在工作中这样做，如果类和文件具有相同的名称，它更容易找到东西。至于性能，你真的不应该在一个项目中有5000个类。如果你这样做，可能会有一些重构。

也就是说，有些情况我们在一个文件中有多个类。那就是它只是文件主类的私有助手类。

Answer 4

除了简单地“更清晰”之外，将类分成单独的文件使得多个开发人员更容易不要彼此踩到脚趾。当提交对版本控制工具的更改时，合并会更少。

Answer 5

+1分离。我刚刚进入一个项目，其中一些类在具有不同名称的文件中，或者与另一个类混为一谈，并且不可能以快速有效的方式找到它们。您可以在构建中投入更多资源 - 您无法弥补丢失的程序员时间，因为他找不到合适的文件进行编辑。

Answer 6

我工作过的大多数地方都遵循这种做法。我实际上已经为BAE（Aust。）编写了编码标准以及原因，而不仅仅是在没有真正理由的情况下刻划一些东西。

关于你关于源文件的问题，编译的时间并不多，但更多的是能够首先找到相关代码片段的问题。不是每个人都在使用IDE。并且知道你只是寻找MyClass.h和MyClass.cpp确实比在一堆文件上运行“grep MyClass *。（h | cpp）”然后过滤掉#include MyClass.h语句节省了时间......

请注意，有大量源文件对编译时间影响的解决方法。请参阅John Lakos的大规模C ++软件设计，以进行有趣的讨论。

您可能还想阅读Steve McConnell撰写的Code Complete，以获得有关编码指南的精彩章节。实际上，这本书是一本非常好的读物，我会不断回访

Answer 7

通常的做法是这样做，尤其是能够在需要它的文件中包含.h。当然性能受到影响，但在出现之前尽量不要考虑这个问题:) 最好从分离的文件开始，然后尝试合并通常一起使用的.h，以提高性能，如果你真的需要的话。这一切都归结为文件之间的依赖关系，这对每个项目都非常具体。

Answer 8

正如其他人所说，最佳做法是从代码维护和可理解性的角度将每个类放在自己的翻译单元中。然而，在大规模系统中，这有时是不可取的 - 请参阅Bruce Dawson在this article中标题为“使那些源文件更大”的部分，以讨论权衡。

Answer 9

我发现这些指南在头文件时特别有用： http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Header_Files

Answer 10

每个文件只有一个类是非常有用的，但是如果你通过包含所有单独C ++文件的bulkbuild文件进行构建，那么由于许多编译器的启动时间相对较大，因此编译速度更快。

Answer 11

我很惊讶几乎所有人都赞成每个班级有一个文件。问题在于，在“重构”的时代。一个人可能很难保持文件和类名同步。每次更改类名时，您都必须更改文件名，这意味着您还必须在包含文件的任何位置进行更改。

我个人将相关的类分组到一个文件中，然后给这样一个文件一个有意义的名字，即使一个类名改变也不会改变。拥有较少的文件也可以更轻松地滚动文件树。 我在Windows上使用Visual Studio，在Linux上使用Eclipse CDT，并且都有快捷键，可以直接进入类声明，因此查找类声明非常简单快捷。

话虽如此，我认为一旦项目完成，或者其结构已经固化，并且名称更改变得罕见，每个文件有一个类可能是有意义的。我希望有一个工具可以提取类并将它们放在不同的.h和.cpp文件中。但我不认为这是必不可少的。

选择还取决于工作项目的类型。在我看来，这个问题并不值得一个黑白回答，因为任何一个选择都有利有弊。

Answer 12

同样的规则在这里适用，但它注意到允许的一些例外情况如下：

• 继承树
• 仅在非常有限范围内使用的类
• 有些公用事业只是放在一般的'utils.h'
中

Answer 13

两个词：奥康的剃刀。每个文件保留一个类，并将相应的标头保存在单独的文件中。如果不这样做，就像每个文件都保留一个功能，那么您就必须创建关于什么构成功能的各种规则。每个文件只保留一个类，可以获得更多的收益。而且，即使一半不错的工具也可以处理大量文件。保持简单，我的朋友。