吸收器和设置器会影响C ++ / D / Java的性能吗？

这取决于。没有普遍的答案永远是正确的。

在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惯例而影响性能。