过早的优化是万恶之源!

根据经验，我通常只内联“getter”和“setter”。一旦代码可以工作并且稳定，分析就可以显示哪些函数可以从内联中受益。

另一方面，大多数现代编译器都有很好的优化算法，并且会内联您应该内联的内容。

推理——编写内联单行函数，以后再考虑其他函数。

内联函数可以通过消除将参数推入堆栈的需要来提高代码性能。 如果有问题的函数在你的代码的关键部分，你应该在项目的优化部分做出内联而不是内联的决定，

你可以在c++ FAQ中阅读更多关于内联的内容

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

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

我经常使用内联函数不是为了优化，而是为了使代码更具可读性。有时代码本身比注释、描述性名称等更短、更容易理解。例如:

void IncreaseCount() { freeInstancesCnt++; }

读者可以立即了解代码的完整语义。

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

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

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

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

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

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

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

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

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

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

最好的方法是检查和比较生成的内联和非内联指令。但是，省略内联总是安全的。使用内联可能会导致您不想要的麻烦。