无论出于何种原因，我们公司都有一个编码准则，其中指出：
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作为我们的日常编译器]
Answers:
这里的术语是翻译单元，您真的希望（如果可能）每个翻译单元具有一个类，即每个.cpp文件具有一个类实现，并且具有相同名称的相应.h文件。
从这种方式（从编译/链接）的角度来看，这样做通常更有效（尤其是在执行诸如增量链接之类的操作时）。想法是，翻译单元是隔离的，这样，当一个翻译单元发生更改时，您不必重新构建很多东西，就像您开始将许多抽象集中到一个翻译单元中一样。
此外，您还会发现许多错误/诊断是通过文件名报告的（“ Myclass.cpp中的错误，第22行”），如果文件和类之间存在一一对应的关系，则将很有帮助。（或者我想您可以将其称为2对1对应关系）。
在目录中每个类具有一组头文件/源文件似乎有点过头了。如果班级数量达到100或1000，甚至会令人恐惧。
但是，按照“让所有东西放在一起”的理念玩弄了源代码之后，得出的结论是，只有撰写文件的人才有希望不会丢失。即使使用IDE，也很容易遗漏任何东西，因为当您处理20,000行的源代码时，您会为任何与您的问题不完全相关的事情而闭嘴。
现实生活中的例子：在这千行源代码中定义的类层次结构将自身封闭为菱形继承，并且某些方法在子类中被具有完全相同代码的方法覆盖。这很容易被忽略（谁想浏览/检查20,000行源代码？），并且当更改原始方法（错误纠正）时，效果不如预期的普遍。
我在模板代码中遇到了这个问题，但是在常规C ++和C代码中也遇到了类似的问题。
将源分成每个结构/类1个标头，您可以：
在源代码控制的代码中，类依赖关系可能导致类在文件中上下移动，以使标头得以编译。在比较不同版本的同一文件时，您不想研究此类移动的演变。
具有单独的标头可以使代码更具模块化，编译速度更快，并且可以更轻松地通过不同版本的差异来研究其演变
对于我的模板程序，我必须将标头分成两个文件：包含模板类声明/定义的.HPP文件，以及包含上述类方法的定义的.INL文件。
将所有这些代码放在一个且只有一个唯一的标头中，意味着将类定义放在此文件的开头，并将方法定义放在末尾。
然后，如果某人只需要一小部分代码，并且仅使用一个标头的解决方案，他们仍然将不得不为较慢的编译付出代价。
（§）请注意，如果知道哪个类拥有哪个类，则可以在类之间具有循环依赖关系。这是关于知道其他类的存在的类的讨论，而不是shared_ptr循环依赖关系反模式。
但是，必须通过多个标头和多个源的解决方案来尊重这一点。
当您包含一个标头时，无论使用哪个标头，您的源代码都必须干净地编译。
每个标题都应该是自给自足的。您应该开发代码，而不是通过捉住10,000多个源文件项目来寻宝，以发现哪一个标头定义了仅因一个枚举而需要包含的1,000行标头中的符号。
这意味着每个标头都定义或正向声明其使用的所有符号，或者包括所有必需的标头（并且仅包含必需的标头）。
下划线-d问：
您能解释一下使用单独的标题对循环依赖有何影响吗？我不这样认为。即使两个类都在同一个标头中完全声明，我们也可以简单地创建一个循环依赖关系，只需在我们在另一个声明句柄之前预先向前声明一个就可以了。其他所有内容似乎都是不错的地方，但是分开的标题有助于循环依赖的想法似乎遥不可及
underscore_d，11月13日在23:20
假设您有2个类模板A和B。
假设类A（分别为B）的定义具有指向B（分别为A）的指针。我们还说A类（分别为B）的方法实际上是从B（分别为A）调用方法的。
您在类的定义及其方法的实现中都具有循环依赖关系。
如果A和B是普通类，并且A和B的方法在.CPP文件中，则不会有问题：您将使用前向声明，为每个类定义提供标头，然后每个CPP都将包含两个HPP。
但是，因为有了模板，实际上您必须在上面重现该模式，但仅使用标头。
这表示：
每个标头将具有以下特征：
天真的用户将包括A.hpp和/或B.hpp，从而忽略了整个混乱。
具有这种组织结构意味着库编写者可以解决A和B之间的循环依赖关系，同时将两个类都保存在单独的文件中，一旦您了解了该方案，就可以轻松浏览。
请注意，这是一个极端情况（两个模板彼此了解）。我希望大多数代码都不需要该技巧。
.hpp和.tpp文件基本上以相同的方式解决了这个问题……但是我的记忆不足以建立关联-也许我阻止了它。：D值得庆幸的是，自那以来，我已经对该区域进行了重构，以减少混乱，因为正如您所指出的那样，这实际上可能是一种很少需要的模式。
我们在工作时会这样做，如果类和文件具有相同的名称，则很容易找到东西。至于性能，您实际上不应在单个项目中拥有5000个类。如果这样做，则可能需要进行一些重构。
也就是说，在某些情况下，一个文件中有多个类。那时它只是文件主类的私有帮助器类。
+1分隔。我刚进入一个项目，其中某些类位于不同名称的文件中，或者与另一类混在一起，因此无法快速有效地找到它们。您可以在构建时投入更多资源-您不能弥补程序员的时间浪费，因为他找不到合适的文件进行编辑。
除了简单地“清晰”之外，将类分成单独的文件还可以使多个开发人员更轻松地相互踩踏。将更改提交到版本控制工具时，合并将更少。
grep还是使用其他方式。例如，键入要容易git log SmallFile.cpp得多git log GiganticFile.cpp | grep -b4 -a4 SureHopeIPutTheMagicWordInEveryCommitMsg（一个人为的示例，但是您明白了）。
我工作过的大多数地方都遵循这种做法。我实际上已经编写了BAE（澳大利亚）的编码标准，并说明了为什么没有理由没有理由仅在石头上雕刻东西的原因。
关于您关于源文件的问题，这不是花太多时间进行编译，而是更多的是能够首先找到相关代码段的问题。并非每个人都在使用IDE。并且知道只查找MyClass.h和MyClass.cpp确实比在多个文件上运行“ grep MyClass *。（h | cpp）”然后过滤掉#include MyClass.h语句节省了时间。
请注意，有一些变通办法可以解决大量源文件对编译时间的影响。有关有趣的讨论，请参见John Lakos的《大规模C ++软件设计》。
您可能还希望阅读Steve McConnell撰写的Code Complete，以获得有关编码准则的出色章节。实际上，这本书是一本不错的书，我会经常回到
我发现这些准则对于头文件特别有用：http : //google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Header_Files
每个文件只有一个类非常有帮助，但是如果您通过包含所有单个C ++文件的bulkbuild文件进行构建，则由于许多编译器的启动时间相对较长，因此编译速度更快。
令我惊讶的是，几乎每个人都赞成每堂课一个文件。这样做的问题是，在“重构”时代，保持文件名和类名同步可能很困难。每次更改类名时，都必须也更改文件名，这意味着还必须在包含文件的所有位置进行更改。
我个人将相关的类分组到一个文件中，然后为该文件提供一个有意义的名称，即使类名称发生更改也不必更改。更少的文件也使滚动浏览文件树变得更加容易。我在Windows上使用Visual Studio，在Linux上使用Eclipse CDT，它们都有快捷键，可以直接转到类声明，因此查找类声明既简单又快捷。
话虽如此，我认为一旦项目完成或者其结构已经“巩固”，并且名称更改变得罕见，那么每个文件只有一个类是有意义的。我希望有一个可以提取类并将其放置在不同的.h和.cpp文件中的工具。但是我认为这不是必不可少的。
选择还取决于一个项目的类型。在我看来，这个问题不值得一black而就，因为这两种选择都有其优缺点。
sed -i 's/\<TheClassName\>/TheNewName/g' In*.?pp=> rename 's/\<TheClassName\>/TheNewName/' In*.?pp。如有必要，重复几个子目录。而且，如果这种方法sed在没有冲突的情况下起作用（或者您写了一个更精确的方法），那么这种rename方法更有可能实现。我几乎没有使用GUI IDE的经验，但是希望它们能使这变得更加容易，所以我没有看到任何问题。