在C++中get/set方法变量的方法声明的编程风格？

Question

如果您在.h文件中声明该类的getters/setters，然后在.cpp中定义它们或者在.h文件中执行这两个操作。你喜欢哪种风格，为什么？我个人喜欢后者，其中所有的都在.h中，而且除了.cpp中的setter/getters之外，只有那些与之相关的逻辑的方法。

Answer 1

对我来说，这取决于谁将使用.h文件。如果它是一个很大程度上在模块内部的文件，那么我倾向于将小方法放在标题中。如果它是一个更外部的头文件，它提供了一个更加固定的API，那么我将把所有的东西放在.cpp文件中。在这种情况下，我经常使用PIMPL Idiom作为完整的编译防火墙。

权衡我把他们的头看到的是：

• 少打字
• 更容易内联编译器
（虽然编译器有时会做多个翻译单位之间的内联反正现在。）
• 更多的编译依赖

Answer 2

我要说的是，头文件应约接口，而不是实现。我会把它们放在.cpp中。

Answer 3

我几乎总是跟随宣布他们的头，并在源定义的划分。每当我不这样做，我最终都不得不回过头去做任何事情。

Answer 4

我把放在头的所有单套只要他们并不需要太多的附加头包括（因为其他类的调用方法）。 我也不要试图把所有的代码在同一行，所以我可以把大部分的方法在头:-)

但无论如何乔希提到一个很好的理由把他们在.cpp：如果标题是供外用。

Answer 5

我更愿意把它们放到.cpp文件，为快速编译/链接倍的缘故。即使是很小的单行程序（空虚拟析构函数）也会浪费你的编译时间，如果它们被实例化了很多。在一个项目中，我可以通过将所有虚拟析构函数移动到.cpp文件中来缩短编译时间。

从那时起，我卖了这一点，我只会把它们放到头，如果再探查告诉我，我可以从内联获利。唯一的缺点是你需要更多的输入，但是如果你在编写头文件时创建.cpp文件，你通常可以复制&粘贴声明并将它们填充到.cpp文件中，所以没有那么糟糕。更糟糕的是，如果你后来发现你想将东西移动到.cpp文件中。

一个不错的副作用是，当您的头文件中只有文档和声明时，阅读内容更简单，尤其是在新开发人员加入项目时。

Answer 6

我使用下一个规则：声明的头，实现的代码文件。这成为实际，当你的头是项目之外使用 - 比更轻量级的标题是，那么它在使用

Answer 7

我宁愿保持.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条语句）。

Answer 8

对我来说这取决于我在做什么与代码。对于我要维护和持续很长时间的代码，我把在.cc文件，原因如下的一切：

• .h文件可以保持稀疏的文档，谁想要寻找函数和方法的人定义。
• 我的团队编码准则声明，我们将所有内容放在.cpp文件中，并且喜欢遵循这些规则，即使函数定义只需要一行。这消除了猜猜游戏的真实位置，因为你知道应该检查哪个文件。
• 如果您正在频繁地重新编译一个大项目，那么将函数定义保存在.cpp文件中会比在头文件中保存函数定义节省一些时间。这一点最近对我们来说很重要，因为我们最近浏览了代码并添加了许多运行时断言语句来验证我们类的输入数据，并且这需要对getter和setter进行很多修改。如果这些方法声明已经存在于.cpp文件中，这会变成我们的干净的重新编译，这可能会花费我的笔记本电脑大约30分钟。

这并不是说我不会随着规则偶尔玩弄快速和肮脏的事物，并在执行某些事情时将事情放在.h文件中，但对于代码，我认真对待所有代码不管长度）在.cpp文件中。对于大项目（有些）规则是有原因的，遵循它们可以是一种美德。说到这一点，我只想到另一个Perl脚本，我可以一起查找违反编码准则的行为。很受欢迎。 :)