访问器应该内联吗？
这是头文件中的声明：
class PrimeSieve
{
populate(int lim);
vector<int> sieve;
long long limit;
public:
unsigned int limit();
};
Should I Define the accessor method in the .cpp file or in the .h, inline?
我是 C++ 新手，但我想遵循最佳实践。我在一些书中看到过这一点——这被认为是标准吗？
unsigned int limit() { return limit; };
This is the declaration in the header file:
class PrimeSieve
{
populate(int lim);
vector<int> sieve;
long long limit;
public:
unsigned int limit();
};
Should I define the accessor method in the .cpp file or in the .h, inline?
I'm new to C++, but I'd like to follow best practices. I've seen this around in some of the books—is this considered standard?
unsigned int limit() { return limit; };
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这些标准不仅仅是一种全球编程标准，而且因组织而异。当然，
getLimit()仍然比单纯的limit()更好。More than being kind of global programming standards, these vary from organizations to organizaions. Of course,
getLimit()would still be better than merelimit().务必将访问器内联写入头文件中。它可以实现更好的优化，并且不会减少封装（因为私有数据格式的更改需要重新编译包含标头的所有单元）。
对于复杂的算法，您可能希望将定义隐藏在实现文件中。或者当实现需要一些类定义不需要的类型/头文件时。这两种情况都不适用于简单访问器。
对于单行话，将其放在类定义中。稍长的成员函数仍应位于头文件中，但可以在类定义之后显式声明
内联。Definitely write the accessor inline in the header file. It makes better optimizations possible, and doesn't reduce encapsulation (since changes to the format of private data require recompiling all units that include the header anyway).
In the case of a complicated algorithm, you might want to hide the definition in an implementation file. Or when the implementation requires some types/header files not otherwise required by the class definition. Neither of those cases applies to simple accessors.
For one-liners, put it inside the class definition. Slightly longer member functions should still be in the header file, but might be declared explicitly
inline, following the class definition.大多数较新的编译器都足够聪明，可以内联必要的内容并保留其他所有内容。因此，让编译器做它擅长的事情，不要试图再次猜测它。
将所有代码放在 .cpp 中，将代码声明放在 .h 中。
Most newer compilers are smart enough to inline what is necessary and leave everything else alone. So let the compiler do what its good at and don't try to second guess it.
Put all your code in the .cpp and the code declarations in the .h.
一个好的经验法则是将所有代码放在 .cpp 文件中，因此这会与 .h 文件中的内联函数发生冲突。
A good rule of thumb is to put all your code in the .cpp file, so this would argue against an inline function in the .h file.
对于类的客户端完全可见的类中的简单数据类型，没有真正的区别，因为每当类定义发生更改时，您都需要重新编译客户端。
创建访问器而不是直接使用成员的主要原因是允许实现稍后删除数据成员并仍然保持接口兼容；如果包含访问器的接口未更改，则结果通常是二进制兼容的，否则，它是源兼容的。让访问器内联意味着将其定义为您要更改的接口的一部分，因此您只能与源兼容。
拥有访问器的另一个原因是 DLL 边界：如果您的访问器需要调用另一个函数，并且您允许内联它，那么该函数的符号也需要导出到客户端。
根据项目的复杂性，将代码的接口定义为抽象类可能会很有帮助，这样您就可以根据自己的喜好更改实现，而客户端却看不到更改；在这种情况下，访问器在接口类中被定义为抽象，并且客户端永远无法内联它们。
For simple data types in classes fully visible to clients of the class, there is no real difference as you need to recompile the client whenever the class definition changes.
The main reason to make an accessor rather than use the member directly is to allow the implementation to remove the data member later on and still keep the interface compatible; if the interface containing the accessor is unchanged, the result is typically binary compatible, otherwise, it's source compatible. Having the accessor inline means defining it as part of the interface that you are changing, so you can ever only be source compatible.
The other reason to have an accessor is a DLL boundary: If your accessor needs to call into another function, and you allow it to be inlined, then this function's symbol needs to be exported to the client as well.
Depending on the complexity of the project, it can be beneficial to define an interface for your code as an abstract class, which allows you to change the implementation to your heart's content without the client ever seeing the change; in this case, accessors are defined as abstract in the interface class and clients cannot inline them, ever.
将访问器声明为内联的理由是，这消除了调用开销，并且可以实现一些进一步的优化。
我对测量性能的经验是，这样做的收益通常相当有限。因此我不再默认这样做。
The argument for declaring the accessor
inlineis that this eliminates the call over-head, and can enable some further optimisations.My experienced of measured performance is that the gain from doing this is usually rather modest. I consequently no longer do it by default.