问题描述
这取决于。没有普遍的答案永远是正确的。
在Java中，JIT编译器可能 迟早 会对其进行内联。据我所知，JVM JIT编译器仅优化频繁使用的代码，因此您可以看到最初的函数调用开销，直到足够频繁地调用getter / setter为止。
在C ++中，几乎可以肯定它会内联（假设启用了优化）。但是，在一种情况下可能不会：
// foo.h
class Foo {
private:
int bar_;
public:
int bar(); // getter
};
// foo.cpp
#include "foo.h"
int Foo::bar(){
return bar_;
}
如果该函数的定义对于该类的用户不可见（它将包含foo.h，但看不到foo.cpp），则编译器可能无法内联该函数调用。
如果启用链接时代码生成作为优化，则MSVC应该能够内联它。我不知道海湾合作委员会如何处理这个问题。
通过扩展，这还意味着，如果在另一个.dll / .so中定义了getter， 则 无法内联调用。
无论如何，我认为琐碎的get / setter不一定是“良好的OOP惯例”，也不是“有其他所有使用它们的原因”。很多人认为琐碎的获取/设置对1）表示设计不好，2）浪费打字。
就个人而言，这不是我对这两种方法都感到不适的事情。对我来说，要使某项东西具有“良好的面向对象操作规范”的资格，就必须产生一些可量化的积极影响。琐碎的get / setter方法有一些边际优势，也有一些微不足道的劣势。因此，我认为这不是好事。如果您确实愿意，它们只是您可以做的事情。
解决方法
这是一个比较古老的话题：二传手和getter是好是坏？
我的问题是：C ++ / D / Java中的编译器是否可以内联吸气剂和吸气剂？
与直接现场访问相比，吸气器/设置器在多大程度上影响性能（函数调用，堆栈框架）。除了使用它们的所有其他原因之外，我想知道它们是否应该作为良好的OOP惯例而影响性能。