首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 开发语言 > C++ >

一个种成员函数,即使inline,又是virtual

2013-04-21 
一个类成员函数,即使inline,又是virtual使用对象调用该函数,使用指针调用该函数,这个函数的inline有用到吗

一个类成员函数,即使inline,又是virtual
使用对象调用该函数,

使用指针调用该函数,

这个函数的inline有用到吗?

还有,构造函数可以inline,感觉很奇怪。
[解决办法]
virtual的含义是子类可以定义完全相同的函数,这个函数在使用指针调用时表现出多态,而inline只是说明这个函数可以优化成某种简章的代码,这很正常啊
[解决办法]
c++要求对一般的内置函数要用关键字inline声明,但对于类内定义的成员函数,可以省略inline,因为这些成员函数已被隐含的指定为内置函数!构造函数就是如此
[解决办法]
virtual的函数也有机会inline。只要在编译期能确定调用的,就有机会inline。
[解决办法]
但如果需要运行时绑定的话,那inline必然是无效的。
[解决办法]

引用:
virtual的函数也有机会inline。只要在编译期能确定调用的,就有机会inline。

virtual 可能在编译时期就调用吗?? 好像都要到运行时期的吧  虚函数可以inline吗 等待!!!!
[解决办法]
引用:
引用:

virtual的函数也有机会inline。只要在编译期能确定调用的,就有机会inline。

virtual 可能在编译时期就调用吗?? 好像都要到运行时期的吧  虚函数可以inline吗 等待!!!!


不一定,通过引用和指针调用的虚函数要到运行期才能确定调用版本……
而通过对象直接调用的虚函数则可以在编译器确定调用版本。


举例:B 是 A的子类,重写了A中的虚函数f
则:
fun(A *pa)
{
   pa->f();//运行期才能确定
   A a;
   a.f(); //这个编译期就可以确定调用版本了
}

int main
{
   A*pa= new B;
   fun(pa);
   return 0;
}

[解决办法]
virtual函数到底调用哪个版本是运行时才决定的,而inline则要求这个决定必须在编译时作出(否则怎么inline),因此这两个关键字很显然是冲突的。如果编译器不抱错,只能说明编译器没有想到程序员这么傻,连这种错都犯!

不管怎么说,inline是非强制的关键字,即使你写了inline,也会被忽略的
[解决办法]
理论上这确实似乎有可能,可是哪个编译器会为这种“特殊情况”去做inline的特殊设计?这个问题的主旨是:inline和virtual到底能不能共存。脱离这个主旨讨论virtual调用能不能编译期确定哪个版本是毫无意义的。请注意virtual出现的目的,你所谓的这种特殊调用,已经背离了virtual的目的,不具有举例的“代表性”
引用:
引用:

引用:

virtual的函数也有机会inline。只要在编译期能确定调用的,就有机会inline。

virtual 可能在编译时期就调用吗?? 好像都要到运行时期的吧 虚函数可以inline吗 等待!!!!


不一定,通过引用和指针调用的虚函数要到运行期才能确定调用版本……
而通过对象直接调……

[解决办法]
inline在正确使用的情况下确实能带来性能上的好处,但它毕竟只是一种编译指示而不是强制(主动权在编译器而不在你),有时候使用inline还会带来不易觉查的问题,还是明智地运用好!

“构造函数和析构函数往往不是inline的最佳候选人,inline并不像你所想像的那般简单和直接。”(参考《Effective C++》)
[解决办法]
其实inline只会在非常短小且非虚函数中才应该被使用。第一个条件是因为此时inline,节省的一个函数调用开销远远小于函数实际执行的开销,因此好处不大,而此时带来的额外空间开销却是非常巨大的(因为inline要把函数体插入到所有调用的地方),而后者则完全不能使用inline,原因我在F9说明了

在我看来,在现代硬件价格趋于无穷小的情况,inline带来的好处完全可以忽略,且即使你不想忽略,编译器也可能随时忽略你。我就从来不用inline
引用:
inline在正确使用的情况下确实能带来性能上的好处,但它毕竟只是一种编译指示而不是强制(主动权在编译器而不在你),有时候使用inline还会带来不易觉查的问题,还是明智地运用好!

“构造函数和析构函数往往不是inline的最佳候选人,inline并不像你所想像的那般简单和直接。”(参考《Effective C++》)

[解决办法]
inline关键字对编译器来说只起“建议”作用,不是说你写个inline就直接展开了
[解决办法]
引用:
其实inline只会在非常短小且非虚函数中才应该被使用。第一个条件是因为此时inline,节省的一个函数调用开销远远小于函数实际执行的开销,因此好处不大,而此时带来的额外空间开销却是非常巨大的(因为inline要把函数体插入到所有调用的地方),而后者则完全不能使用inline,原因我在F9说明了



在我看来,在现代硬件价格趋于无穷小的情况,inline带来的好处完全可以忽略,且即使你不想忽略,……



我在inline上就吃过亏,所以我比较赞同你的观点,即:其实inline只会在非常短小且非虚函数中才应该被使用。但,“在现代硬件价格趋于无穷小的情况,inline带来的好处完全可以忽略,且即使你不想忽略,编译器也可能随时忽略你。我就从来不用inline”这样说似乎这有点过激了,毕竟有些环境还是昂贵的,是吧?
[解决办法]
理论上冲突啊。但编译器自己做了聪明的处理也未可知。

热点排行