最好的方法是分析你的程序，把那些被多次调用并消耗CPU周期的小函数标记为内联函数。这里的关键字是“小”——一旦函数调用开销与函数中花费的时间相比可以忽略不计，那么内联它们就没有意义了。

我建议的另一种用法是，如果你有一些小函数在性能关键代码中经常被调用，以至于缓存不相关，你可能也应该内联这些函数。同样，这也是侧写师应该能够告诉你的。

我读了一些答案，发现有些东西缺失了。

我使用的规则是不使用内联，除非我希望它是内联的。看起来很傻，现在解释一下。

编译器足够聪明，短函数总是内联的。永远不要让长函数作为内联函数，除非程序员说这样做。

我知道内联是一个提示或请求编译器

实际上，内联是编译器的一个命令，它没有选择，并且在内联关键字之后使所有代码内联。所以你永远不能使用内联关键字和编译器将设计最短的代码。

那么什么时候使用内联呢?

如果您想内联一些代码，则使用。我只知道一个例子，因为我只在一种情况下使用它。即用户认证。

例如，我有这样一个函数:

inline bool ValidUser(const std::string& username, const std::string& password)
{
    //here it is quite long function
}

不管这个函数有多大，我都想把它作为内联的，因为它使我的软件更难破解。

在决定是否使用内联时，我通常记住以下想法:在现代机器上，内存延迟可能是比原始计算更大的瓶颈。众所周知，经常调用的内联函数会增加可执行文件的大小。此外，这样的函数可以存储在CPU的代码缓存中，当需要访问代码时，这将减少缓存失败的数量。

因此，您必须自己决定:内联是否会增加或减少生成的机器代码的大小?调用该函数会导致缓存丢失的可能性有多大?如果它遍布整个代码，那么我认为可能性很高。如果它被限制在一个单一的紧密循环，那么可能性很低。

我通常使用内联的情况下，我列出如下。然而，当您真正关心性能时，概要分析是必不可少的。此外，您可能希望检查编译器是否真的接受了提示。

在紧密循环中调用的简短例程。 非常基本的访问器(get / set)和包装器函数。 不幸的是，头文件中的模板代码会自动获得内联提示。 像宏一样使用的短代码。(例如min() / max()) 简短的数学程序。

当你认为你的代码足够小，可以作为内联使用，记住内联函数复制你的代码，并在函数被调用时粘贴它，这样可能会增加你的执行时间，但也会增加内存消耗。 当你使用循环/静态变量/递归/切换/goto/虚函数时，你不能使用内联函数。 虚的意思是等到运行时，内联的意思是在编译期间，所以它们不能同时使用。

我通常遵循一个拇指规则，我用3-4个简单的语句作为内联函数。但最好记住，这只是给编译器的一个提示。最终是否使它内联的调用仅由编译器执行。如果有超过这些语句，我不会用一个愚蠢的编译器进行内联声明，这可能会导致代码膨胀。

此外，在维护大型项目时，内联方法有严重的副作用。当内联代码被更改时，所有使用它的文件将由编译器自动重建(如果它是一个好的编译器)。这可能会浪费大量的开发时间。

当内联方法被传输到源文件而不再内联时，整个项目必须重新构建(至少这是我的经验)。当方法转换为内联时也是如此。