【发布时间】：2009-01-24 18:35:51
【问题描述】：
您应该在 .h 文件中声明类的 getter/setter，然后在 .cpp 中定义它们，还是在 .h 文件中都这样做。你喜欢哪种风格，为什么？我个人喜欢后者，其中所有这些都在 .h 中，并且只有与 .cpp 中的 setter/getter 具有关联的逻辑的方法。
【问题讨论】：
标签： c++ coding-style
【发布时间】：2009-01-24 18:35:51
【问题描述】：
对我来说，这取决于谁将使用 .h 文件。如果它是一个主要在模块内部的文件，那么我倾向于将微小的方法放在标题中。如果它是一个更外部的头文件，提供更固定的 API，那么我会将所有内容放在 .cpp 文件中。在这种情况下，我会经常使用PIMPL Idiom 作为完整的编译防火墙。
我看到将它们放在标题中的权衡是：
- 少打字
- 编译器更容易内联（尽管编译器现在有时可以在多个翻译单元之间进行内联。）
- 更多编译依赖
【讨论】：
我会说头文件应该是关于接口，而不是实现。我会把它们放在 .cpp 中。
【讨论】：
对我来说，这取决于我对代码所做的事情。对于我想要维护和持续使用的代码，我将所有内容都放在 .cc 文件中，原因如下：
- 对于想要查找函数和方法定义的人来说，.h 文件可以作为文档保持稀疏。
- 我小组的编码指南规定，我们将所有内容都放在 .cpp 文件中并喜欢遵循这些内容，即使函数定义只占用一行。这消除了关于事物实际位置的猜测游戏，因为您知道应该检查哪个文件。
- 如果您经常重新编译大型项目，与将函数定义保存在头文件中相比，将函数定义保存在 .cpp 文件中可以节省一些时间。这对我们来说最近很重要，因为我们最近检查了代码并添加了许多运行时断言语句来验证我们的类的输入数据，这需要对 getter 和 setter 进行大量修改。如果这些方法声明存在于 .cpp 文件中，这对我们来说将变成一个干净的重新编译，这在我的笔记本电脑上可能需要大约 30 分钟。
这并不是说我不会偶尔玩弄规则并且在实现非常快速的东西时将内容放入 .h 文件中，但是对于代码我很认真地对待我所有的代码（无论长度) 在 .cpp 文件中。对于大型项目（某些）来说，规则的存在是有原因的，遵守它们可能是一种美德。
说到这里，我只是想到了另一个 Perl 脚本，我可以一起破解来找出违反编码准则的情况。受欢迎是好事。 :)
【讨论】：
-
在您的第一点中，我认为您的意思是声明而不是定义。
只要不需要包含太多额外的标题（因为调用其他类的方法），我就把所有的单行放在标题中。 此外，我不会尝试将所有代码放在一行中，因此我可以将大部分方法放在标题中:-)
但 Josh 提到了将它们放在 .cpp 中的一个很好的理由：如果标头是供外部使用的。
【讨论】：
我更喜欢保持 .h 文件尽可能干净。因此，像 get/set 这样简单的小函数，我经常将其作为内联定义的函数放入单独的文件中，然后将该文件（我使用扩展名 .inl）包含到 .h 头文件中：
// foo.h
class foo
{
public:
int bar() const;
private:
int m_bar;
};
#include "foo.inl"
// foo.inl
inline
int foo::bar() const
{
return m_bar;
}
我认为这提供了两全其美的效果，同时从头文件中隐藏了大部分实现，并且仍然保持内联简单代码的优势（根据经验，我将其保留在最多 3 个语句中)。
【讨论】：
-
“隐藏从 goto-zealots”更像是它。以我有限的经验，可能有很多 bar() { return m_bar; } “getters”，所以你添加的混乱没有任何好处。成员引用在性能上与任何类型的实际计算都非常不同，你真的想隐藏吗？
我几乎总是遵循在标题中声明它们并在源代码中定义的划分。每次我不这样做，我最终都不得不回去再做任何事。
【讨论】：
为了加快编译/链接时间，我更喜欢将它们放入 .cpp 文件中。即使是很小的单行代码（空的虚拟析构函数！），如果它们被大量实例化，也会导致编译时间变长。在一个项目中，我可以通过将所有虚拟析构函数移动到 .cpp 文件中来将编译时间缩短几秒钟。
从那时起，我对此感到满意，如果分析器告诉我可以从内联中获利，我只会将它们再次放入标题中。唯一的缺点是您需要更多的输入，但是如果您在编写标题时创建 .cpp 文件，您通常可以复制和粘贴声明并将它们填写到 .cpp 文件中，所以这还不错。当然更糟糕的是，如果您后来发现您想将内容移动到 .cpp 文件中。
一个很好的副作用是，当您的标题中只有文档和声明时，阅读内容会更简单，尤其是在新开发人员加入项目时。
【讨论】：
我使用下一条规则：声明头，实现代码文件。当您的标头在项目之外使用时，它成为实际 - 比您的标头更轻巧，使用起来更舒适
【讨论】：