我知道内联是对编译器的提示或请求，用于避免函数调用开销。
那么，在什么基础上可以确定一个函数是否是内联的候选人? 在哪种情况下应该避免内联?
当前回答
我读了一些答案，发现有些东西缺失了。
我使用的规则是不使用内联，除非我希望它是内联的。看起来很傻，现在解释一下。
编译器足够聪明，短函数总是内联的。永远不要让长函数作为内联函数，除非程序员说这样做。
我知道内联是一个提示或请求编译器
实际上，内联是编译器的一个命令，它没有选择，并且在内联关键字之后使所有代码内联。所以你永远不能使用内联关键字和编译器将设计最短的代码。
那么什么时候使用内联呢?
如果您想内联一些代码，则使用。我只知道一个例子，因为我只在一种情况下使用它。即用户认证。
例如，我有这样一个函数:
inline bool ValidUser(const std::string& username, const std::string& password)
{
//here it is quite long function
}
不管这个函数有多大，我都想把它作为内联的，因为它使我的软件更难破解。
其他回答
我通常遵循一个拇指规则，我用3-4个简单的语句作为内联函数。但最好记住，这只是给编译器的一个提示。最终是否使它内联的调用仅由编译器执行。如果有超过这些语句，我不会用一个愚蠢的编译器进行内联声明，这可能会导致代码膨胀。
内联与优化关系很小。内联是给编译器的指令，如果给定的函数定义在程序中多次出现，则不会产生错误，并承诺该定义将出现在使用它的每次翻译中，并且在出现它的任何地方都具有完全相同的定义。
根据上述规则，内联适用于短函数，其函数体不需要包含超出声明所需的额外依赖项。每次遇到定义时，都必须对其进行解析，并可能生成其主体的代码，因此对于在单个源文件中只定义一次的函数，这意味着一些编译器开销。
编译器可以内联(即用执行该函数操作的代码替换对函数的调用)它选择的任何函数调用。过去的情况是，它“显然”不能内联一个没有在同一个翻译单元中声明的函数，但随着链接时间优化的使用越来越多，现在这种情况也不存在了。同样正确的是，标记为内联的函数可能不是内联的。
只有当函数代码很小时，才应该使用内联函数限定符。如果函数比较大，则应该使用普通函数，因为节省内存空间可以换取相对较小的执行速度牺牲。
内联函数可以通过消除将参数推入堆栈的需要来提高代码性能。 如果有问题的函数在你的代码的关键部分，你应该在项目的优化部分做出内联而不是内联的决定，
你可以在c++ FAQ中阅读更多关于内联的内容
过早的优化是万恶之源!
根据经验，我通常只内联“getter”和“setter”。一旦代码可以工作并且稳定，分析就可以显示哪些函数可以从内联中受益。
另一方面，大多数现代编译器都有很好的优化算法，并且会内联您应该内联的内容。
推理——编写内联单行函数，以后再考虑其他函数。
