我应该何时inline在C++中为函数/方法编写关键字？
看到一些答案,一些相关的问题:
我应该何时不写在C++函数/方法关键字"内联"？
什么时候编译器不知道何时使函数/方法'内联'？
当一个应用程序为函数/方法写入"内联"时,是否多线程是否重要？
在C++中使用内联函数的优点/缺点是什么？我看到它只会提高编译器输出的代码的性能,但是使用今天的优化编译器,快速CPU,大容量存储器等(不像1980年那样<内存稀缺,一切都必须适合100KB内存)什么他们今天真的有优势吗？
当我收到代码评论评论说虚拟功能不需要内联时,我收到了这个问题.
我认为在直接在对象上调用函数的场景中,内联虚函数可以派上用场.但是我想到的反驳论点是 - 为什么要想定义虚拟然后使用对象来调用方法呢？
最好不要使用内联虚拟功能,因为它们几乎从未扩展过吗？
我用于分析的代码片段:
class Temp
{
public:
virtual ~Temp()
{
}
virtual void myVirtualFunction() const
{
cout<<"Temp::myVirtualFunction"<<endl;
}
};
class TempDerived : public Temp
{
public:
void myVirtualFunction() const
{
cout<<"TempDerived::myVirtualFunction"<<endl;
}
};
int main(void)
{
TempDerived aDerivedObj;
//Compiler thinks it's safe to expand the virtual functions
aDerivedObj.myVirtualFunction();
//type of object Temp points to is always known;
//does compiler still expand virtual functions?
//I doubt compiler would be this much intelligent!
Temp* pTemp = &aDerivedObj;
pTemp->myVirtualFunction();
return …虽然在某些情况下使用内联函数会非常方便,
内联函数有什么缺点吗？
结论:
显然,使用内联函数没有任何问题.
但值得注意的是以下几点!
过度使用内联实际上可以使程序变慢.根据函数的大小,内联它可能会导致代码大小增加或减少.内联一个非常小的访问器函数通常会减少代码大小,而内联一个非常大的函数可以大大增加代码大小.在现代处理器上,较小的代码通常由于更好地使用指令缓存而运行得更快. - Google指南
随着函数大小的增加,内联函数的速度优势趋于减小.在某些时候,与函数体的执行相比,函数调用的开销变小,并且失去了好处- Source
内联函数可能无法正常工作的情况很少:
__inline仅当指定optimize选项时,关键字才会使函数内联.如果指定了optimize,则是否__inline遵循优先级取决于内联优化程序选项的设置.默认情况下,只要运行优化程序,内联选项就会生效.如果指定optimize,则还必须指定noinline选项(如果要__inline忽略关键字).-资源
我们的应用程序的源代码是数十万行,数千个文件,并且在非常古老的地方 - 该应用程序最初是在1995年或1996年编写的.在过去的几年里,我的团队已经大大提高了源代码的质量,但是一个问题仍然是特别困扰我:许多类在其头文件中完全定义了许多方法.
在某些情况下,我对在头文件中内联声明的方法没有任何问题 - 一个struct的构造函数,一个简单的方法,其中内联可以使它更快(我们有一些像这样的数学函数),等等.但内联方法的自由使用没有明显原因是:
最后一个原因现在可能会给我们带来问题,这是通过代码库并将大多数定义移动到源文件的一个很好的理由.
我们的代码库非常庞大. 是否有可以为我们(大部分)做这个的自动化工具？
笔记: