我知道内联是对编译器的提示或请求,用于避免函数调用开销。
那么,在什么基础上可以确定一个函数是否是内联的候选人? 在哪种情况下应该避免内联?
我知道内联是对编译器的提示或请求,用于避免函数调用开销。
那么,在什么基础上可以确定一个函数是否是内联的候选人? 在哪种情况下应该避免内联?
当前回答
当你认为你的代码足够小,可以作为内联使用,记住内联函数复制你的代码,并在函数被调用时粘贴它,这样可能会增加你的执行时间,但也会增加内存消耗。 当你使用循环/静态变量/递归/切换/goto/虚函数时,你不能使用内联函数。 虚的意思是等到运行时,内联的意思是在编译期间,所以它们不能同时使用。
其他回答
最好的方法是检查和比较生成的内联和非内联指令。但是,省略内联总是安全的。使用内联可能会导致您不想要的麻烦。
此外,在维护大型项目时,内联方法有严重的副作用。当内联代码被更改时,所有使用它的文件将由编译器自动重建(如果它是一个好的编译器)。这可能会浪费大量的开发时间。
当内联方法被传输到源文件而不再内联时,整个项目必须重新构建(至少这是我的经验)。当方法转换为内联时也是如此。
我读了一些答案,发现有些东西缺失了。
我使用的规则是不使用内联,除非我希望它是内联的。看起来很傻,现在解释一下。
编译器足够聪明,短函数总是内联的。永远不要让长函数作为内联函数,除非程序员说这样做。
我知道内联是一个提示或请求编译器
实际上,内联是编译器的一个命令,它没有选择,并且在内联关键字之后使所有代码内联。所以你永远不能使用内联关键字和编译器将设计最短的代码。
那么什么时候使用内联呢?
如果您想内联一些代码,则使用。我只知道一个例子,因为我只在一种情况下使用它。即用户认证。
例如,我有这样一个函数:
inline bool ValidUser(const std::string& username, const std::string& password)
{
//here it is quite long function
}
不管这个函数有多大,我都想把它作为内联的,因为它使我的软件更难破解。
只有当函数代码很小时,才应该使用内联函数限定符。如果函数比较大,则应该使用普通函数,因为节省内存空间可以换取相对较小的执行速度牺牲。
过早的优化是万恶之源!
根据经验,我通常只内联“getter”和“setter”。一旦代码可以工作并且稳定,分析就可以显示哪些函数可以从内联中受益。
另一方面,大多数现代编译器都有很好的优化算法,并且会内联您应该内联的内容。
推理——编写内联单行函数,以后再考虑其他函数。