什么时候应该使用内联函数?

发布于 2024-11-25 09:43:39 字数 308 浏览 1 评论 0原文

可能的重复:
我应该何时编写关键字“inline”函数/方法?

我有一个关于 C++ 中内联函数的问题。 我知道内联函数用于用内联函数体替换每个外观。 但我不知道什么时候用它。都说内联函数可以提高性能,但是什么时候应该考虑使用内联函数呢?

Possible Duplicate:
When should I write the keyword 'inline' for a function/method?

I have a question about inline functions in c++.
I know inline functions are used to replace each apperance with the inline function body.
But I do not know when to use it. It is said that inline functions can improve performance, but when should I consider using an inline function?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

小姐丶请自重 2024-12-02 09:43:39

内联函数最适合性能关键且随处重用但编写起来很普通的小型代码存根。

但是,您也可以使用它们来拆分代码,因此您可能最终会将其拆分为几个 100 行长的方法,而不是使用 1000 行长的函数。您可以内联这些,这样它就具有与 1000 行长方法相同的效果。

现代编译器会自动内联一些较小的方法,但是您始终可以手动内联较大的方法。

有很多关于此的资源,例如:

Inline functions are best for small stubs of code that are performance-critical and reused everywhere, but mundane to write.

However, you could also use them to split up your code, so rather than having a 1000-line long function, you may end up splitting this up into a couple of 100-line long methods. You could inline these so it would have the same effect as a 1000-line long method.

Modern compilers will automatically inline some of your smaller methods, however you can always manually inline ones that are bigger.

There are many resources about this, for example:

半夏半凉 2024-12-02 09:43:39

通常,现代编译器足够智能,可以将某些小函数内联到一定限度(以空间增量)。您可以提供提示。当然,您将内联小的重复函数,以节省调用的开销。

另请注意,有时,即使您提供 inline 关键字,编译器也可以决定不内联该函数,因此它的使用(至少出于优化目的)提供了一些信息。

Usually modern compilers are intelligent enough to inline certain small functions to a limit (in increment of space). You can provide the hint. Of course, you'll inline small, repetitive functions that save the overhead of the call.

Note also, that sometimes, even when you provide the inline keyword, the compiler can decide not to inline that function, so its use (for optimization purposes, at least) is somewhat informative.

沉鱼一梦 2024-12-02 09:43:39

大多数现代编译器都足够聪明,可以应用内联函数的优化,可能最好让编译器决定它。

内联只是一个建议,编译器可以自由地拒绝它或应用它。
如果满足以下条件,您可以考虑将函数设为内联:

  • 函数很小
  • 您可以使用内联函数而不是预处理器指令 #define

Most of the modern compilers are smart enough to apply optimization of inlining functions, Probably best to let the compiler decide it.

inline is just a suggestion and the compiler is free to reject it or apply it.
You might consider making a function inline if:

  • A function is small
  • You can use inline function instead of a preprocssor directive #define
梦过后 2024-12-02 09:43:39

inline 关键字的目的是允许您在多个编译单元中定义相同的函数(通常通过在多个源文件包含的头文件中定义它)。在某些编译器上,如果您希望编译器能够考虑将其内联到多个编译单元中,则这一点至关重要。

因此,如果您在头文件中定义函数,则应始终将其声明为内联函数,否则如果该文件包含在多个源文件中,则会出现链接错误。 (如果它是类成员函数,您可以在类内部定义它;这会隐式声明它内联)。如果您在源文件中定义它,那么如果您认为它是内联的良好候选者(例如,如果它很小,或者仅从一个位置调用),则可以将其声明为内联(如果您愿意)。

然而,编译器通常认为他们比你更了解哪些函数;有些可能会将 inline 声明作为提示,而另一些可能会完全忽略它。有些可能提供非标准扩展来强制函数内联(或不内联);仅当您确定(通过测量)它会改进编译器的决策时才使用它们,因为不明智的内联会损害性能。

The purpose of the inline keyword is to allow you to define the same function in multiple compilation units (usually by defining it in a header file included from multiple source files). On some compilers, this is essential if you want the compiler to be able to consider it for inlining in more than one compilation unit.

So, if you define a function in a header file, then you should always declare it inline, otherwise you'll get link errors if the file is included from more than one source file. (If it's a class member function, you could define it inside the class instead; that implicitly declares it inline). If you define it in a source file, then you can declare it inline if you think it's a good candidate for inlining (e.g. if it's small, or only called from one place) if you like.

However, compilers generally think they have a better idea which functions than you do; some may take an inline declaration as a hint, and others may completely ignore it. Some may provide non-standard extensions to force functions to be (or not to be) inlined; only use those if you're sure (by measurement) that it will give an improvement over the compiler's decision, as unwise inlining can hurt performance.

狠疯拽 2024-12-02 09:43:39

当您认为重复调用函数比简单地将函数体放在主代码中花费更多时间时(换句话说,当函数体很小并且函数被重复调用时),您应该使用内联函数)。但是,编译器通常会优化代码,并且可能会忽略已定义为内联的函数。 SO 上还有许多其他线程更详细地处理这个问题。

You should use an inline function when you think that repeated calls to the function would take more time than simply placing the body of the function within the main code (in other words, when the body of the function is small and the function gets called repeatedly). However, compilers generally optimize code and may ignore functions that have been defined as inline. There are many other threads on SO that deal with this in greater detail.

青朷 2024-12-02 09:43:39

前面所说的一切看起来都是正确的,我只是想警告你一个常见的错误,因为你谈论的是性能。

一些程序员错误地认为“内联”=更快,因为节省了函数调用的开销。是的,节省了开销,但是如果您的内联函数编译成比函数调用更大的代码(发生得非常快),则整个代码将会变得更大。然后,它会增加您的代码不适合处理器缓存的可能性。如今,缓存就是一切...因此,您的“内联”代码实际上会运行得更慢...

我想说,“内联”的使用仅适用于直接在 .h 中编写的简单 getter/setter 函数。

对于其他一切,我建议不要使用“内联”并让编译器自行决定。

一般建议:除了一般概念之外,您不应该考虑优化,直到一切都运行并且您可以测量哪些操作占用了处理时间。它通常不到代码的 20%,因此您不必浪费时间盲目优化其他所有内容。通过测量,您可以立即查看优化(例如在这里或那里添加一些内联)是否确实有效。

Everything said before looks correct, I just want to warn you about a common mistake since you speak about performance.

Some programmers incorrectly think that "inline" = faster because the overhead of the function call is saved. Yes, the overhead is saved, but if your inline function compile into a bigger code than a function call (which happen very quickly), the whole code will get bigger. It then increase the probability that your code will not fit in the processor cache. And cache is everything today... So your "inlined" code will actually run more slowly...

I would say the use of "inline" is only OK for trivial getter/setter functions written directly in the .h.

For everything else, I would advise not to use "inline" and let the compiler decide itself.

And a general advice : apart from the general conception, you should not think about optimisation until everything run and you can make measurements of which operations takes the process time. It usually is less than 20% of the code, so you don't waste your time blindly optimizing everything else. And with measurements, you can immediately see if an optimisation (for example adding some inline here and there) actually works or not.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文