我应该把类放在C ++的单独文件中吗？

Question

我问这个问题来组织我的代码。

Answer 1

C和C ++约定是每个库的一个头文件，或库的一部分，而不是每个类的一个头文件。尝试将相关课程组合在一起。例如，在标准库<set>中包含std::set和std::multi_set，但这些模板的功能非常相似。

虽然没有任何真正一致的公共标题规则 - Boost.asio有一个很大的头文件。 Boost.DateTime被合理地划分得很远，但仍然没有达到单一类型的水平。

如果您愿意，可以将每个类的成员函数的实现放在一个源文件中。如果您遵循GNU C样式，即使每个函数都有一个源文件，尽管我认为我不建议使用C ++。并且您可以通过让它们包含多个单独的标头来实现面向公众的头文件。

它可能同样依赖于您的版本控制和构建过程 - 在不触及包含与该类无关的任何内容的任何文件的情况下更改类很方便，因为最小的重建和更改日志清楚地标识了已更改的内容从文件名。但是，一个类不一定是被认为是“无关代码”的边界。

例如，如果您正在使用迭代器编写集合，或者使用某个框架来注册侦听器的类，其中侦听器将在主类上执行操作，则将它们分开是没有多大意义的。从口头上讲，这些都是“内部类”，即使你没有在C ++中将它们实现为嵌套类。

Answer 2

我喜欢将相关的类保存在同一个文件中。

例如，如果我有一个在另一个类中的for_each循环中使用的仿函数，那么我通常不会将它放在自己的文件中。这似乎过分了 - 并将代码与使用过多的代码分开。

但是，一般情况下，我尝试将类分开，并尝试为.hpp文件组合一个合理的树结构，将它们组合在一起使用。在这棵树的头部，我喜欢捕获包含整个库的所有头文件。

Answer 3

是。作为一般规则，每对一个.h / .cpp一个类。文件应该在课程后面命名。

Answer 4

这取决于应用程序。对于某些应用程序，如果它们紧密耦合，则将一组.h / .cpp文件中的不同类组合在一起是有意义的。否则，将类拆分为头文件和源文件的标准绝对是正确的方法。

Answer 5

如果有意义的话，您应该将C ++类放在单独的文件中。通过精心设计的课程，它经常会这样做。它简化了编码，维护，模块化，重构和重用。

然后你有MyClass.h，其中包含class MyClass {...}和MyClass.cpp，其中包含所有MyClass的方法。

如果你有很多小班，这有点疯狂，所以考虑几个选项：

• 以命名空间命名的文件，例如MyNamespace.h，MyNamespace.cpp
• 嵌套类 - 将类定义包装在另一个类中是否有意义？通过执行此操作，您可以说嵌套类在没有父级的情况下不太可能有用。

通过使每个文件名与C ++命名空间或类名一致，可以避免一组额外的命名约定，这样可以避免考虑新名称或从一种约定转换为另一种约定。

Google样式指南也有一个观点，更喜欢带有下划线的文件名。见http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#File_Names

Answer 6

是的，将单独的类保存在单独的cpp文件中，然后使用类名命名文件是一种很好的做法。事实上，Java迫使你这样做。