内联getter和setter是否是一个好习惯？
public: inline int GetValue() const { return m_nValue; } inline void SetValue(int nNewValue) { this -> m_nValue = nNewValue; } 在学习C ++的时候 ，他们说会跑得更快。 所以，我认为在getter和setter上使用会很好。 但是，也许有一些缺点呢？
我不直接插入任何东西，直到一个探查器明确地告诉我不内联导致性能问题。
C ++编译器非常聪明，几乎可以肯定会为你自动内联这样简单的函数。 通常它比你更聪明，而且在确定应该或不应该内联的内容方面做得更好。
我会避免考虑是否需要内联和专注于解决scheme。 稍后添加inline关键字（这不是内联BTW的保证）很容易实现，并且可以使用探查器轻松find潜在的地方。
如果您在定义中写入它们，默认情况下将它们视为inline 。
这意味着它们将被允许在多个编译单元中（因为类定义本身通常出现在多个编译单元中）， 而不是实际上被内联。
这是公共API中的错误做法对这些函数的任何更改都需要重新编译所有客户端。
一般来说 ，吸气剂和吸附剂显示出很差的抽象，不要这样做。 如果你不断地去看另一个类的原始数据，那么你可能需要重新安排你的类，而不是考虑如何操作类中的数据并提供适当的方法。
负面点：
-
编译器可以自由地忽略你。
-
对这些function的任何更改都需要重新编译所有客户端。
-
一个好的编译器会适当地内联非内联函数。
我还想补充一点，除非你每帧执行数百万次获取/设置，否则这些是否被内联几乎是无关紧要的。 老实说，失去睡眠是不值得的。
另外，请记住，仅仅因为您将“内联”一词放在声明+定义的前面，并不意味着编译器将内联您的代码。 这是使用各种启发式algorithm是否有意义，这往往是速度与大小的经典折衷。 然而，在VC ++（我不确定它在GCC中是什么）这个蛮力的'__forceinline'关键字，这是踩在编译器幻想启发式。 我真的不推荐它，除此之外，一旦你移植到不同的架构，这可能是不正确的。
尝试把所有的函数定义放在实现文件中，并保留头文件的纯声明（除非你是模板元编程（STL / BOOST / etc），在这种情况下，几乎所有东西都在头文件中）
人们喜欢内嵌（至less在电子游戏，这是我来自哪里）的经典场所之一是在math标题。 交叉/点产品，vector长度，matrix清除等常常放在头，我认为是不必要的。 9/10对性能没有任何影响，如果你需要做一个紧密的循环，比如用一些matrix变换一个大的vector数组，你可能最好是手工做内联math，或者更好的编码平台特定的汇编程序。
哦，还有一点，如果你觉得你真的需要一个类比数据更多的数据，考虑使用好的旧的结构，这不会带来抽象的OO的行李，这就是它的存在。 🙂
对不起，这并不意味着这么多，但我认为这有助于考虑真实世界的使用情况，而不是太过于迂腐的编译器设置（相信我，我一直在那里））
祝你好运。
巴蒂尔
代码会稍微编译一下，你会失去封装。 一切都取决于项目的规模和性质。 在大多数情况下，如果它们没有任何复杂的逻辑，就可以将它们内联。
顺便说一句，如果直接在类定义中实现，则可以跳过inline 。
通过将代码放在标题中，您将暴露内部类的运作。 客户可以看到这一点，并假设你的class级工作。 这可能会使得在不中断客户端代码的情况下更改类更加困难。
我会说，你不需要为此而烦恼。 阅读关于内联的FAQ部分 。
没有必要，开始相信编译器，至less对于这样的优化！
“但不总是”
inline关键字在你的情况下是没有意义的
编译器将内联你的function，如果可以和想要，无论关键字。
关键字内联影响链接和不内联。 这有点令人困惑，但请仔细阅读。
如果定义是在不同的编译单元（预处理器之后的源文件，基本上）比调用，只有整个项目优化和链接时间代码生成启用才可能内联。 启用它大大增加了链接时间（因为它实际上重新编译链接器中的所有内容），但显然可以提高性能。 不知道在GCC和VS中是否默认打开或closures。
我得说，我没有强烈的厌恶这种做法，这个线程上的其他人似乎有。 我同意，除了使用最多的案例之外，来自内联的性能收益是微不足道的。 （是的，我在实践中遇到了这样的情况。）我在哪里进行这种内联，我是为了方便而做的，一般只是为了这样的一行。 在我的大部分用例中，如果我改变它们的话，在客户端上避免重新编译的需求并不那么强烈。
是的，您可以删除inline ，因为这是实施的位置所暗示的。
另外，对于访问者的激烈程度，我感到有些惊讶。 你几乎不会用任何一个OO语言在一个class上打喷嚏，而且他们毕竟是一个有效的从界面抽象实现的技术，所以把它们称为不好的OO练习是有点受虐狂的。 不要盲目地写访问者是一个很好的build议，但我也build议你不要为了根除这些访问者而失去热情。
拿那个，纯粹主义者。 🙂
