比如这样的：
ObjectInterface* a = new Object();
a->do_something();
一般的编译器优化能否把do_something在编译时确定？
@怪兽大战魔人 @豌豆夹吧

这个真不是太清楚
既然是虚函数，应该会丢到运行时来确定吧
虽然具体的例子可能在编译期就能够确定，但我想了下要做到这点有点麻烦，而且也没啥特别的好处，另外也有可能有某些我还没想清楚的风险导致都被丢到运行时了…………
另外，你指的优化是啥？内联？

@怪兽大战魔人
比如某个stream是这样实现：
struct stream_interface {
virtual char getch() = 0;
};
struct mystream: public stream_interface {
virtual char getch() { ...blabla... };
};
使用的时候：
stream_interface* s = new mystream();
while (bla) {
blabla = s->getch(); // 这里要是还按普通的运行时vtable查地址的话不是慢死了么。。
}

理论上允许优化成非多态调用，至少C++的语义显然没有禁止。
比如a->do_something();中*a在运行时的动态类型如果能被确定，这个调用就可能被优化成a->A::do_something();这个非多态调用。
但是C++也没有指定虚函数多态调用能在编译时求值的特性（比如virtual和constexpr矛盾），因此实现需要自己分析。
这里如果a没有linkage，优化起来会相对容易，整个过程内推断一遍就行。但是只要有linkage，推断*a的动态类型就得靠过程间优化；如果具有external linkage可能得LTO。相当麻烦。
实际实现有多少我没调查过，不过估计指望不上。麻烦是一个原因；另外就算没优化，这种开销一般也不是很大。

当然这种优化结合inline以后效果可能是会比较明显。
不过会while里面一个劲调用虚函数然后感觉到瓶颈的C艹用户就没多少……如果会在这里出问题基本上就是用抽了。
最后，要增加优化机会，加final。

简单验证了下：
struct I {
virtual unsigned X() = 0;
};
struct A: public I {
virtual unsigned X() {
return 12345678;
}
};
int main() {
A a;
I* ia = &a;
return ia->X();
}
用gcc -O -S：
main:
.LFB1:
>>>>.cfi_startproc
>>>>movl>>>>$12345678, %eax
>>>>ret
>>>>.cfi_endproc

可以被优化，但是不知道有什么编译器这么做了。。

这个问题细想还是有点意思
如果是同一个unit下的，理论上确实可以优化
不过因为涉及到函数外的数据段，通常局限于过程的优化是不会干这种事的……撑死是优化到最简的偏移+load出来，然后call
没试过ICC，不知道做了很多过程间优化的ICC会怎么样，总觉得也玄的样子

看来g++的-O2启用的-fdevirtualize和-fdevirtualize-speculatively就会干这个。Clang++也没理由没有。
搜了下发现理论早就有了。
还找到两年前ICPC开IPO的bug，把不该内联的内联了……

http://stackoverflow.com/questions/7046739/lto-devirtualization-and-virtual-tables
还有dt到不老实用C艹直接艹C的……

virtual在确定绑定的时候可以inline吧 两个关键字不冲突

-lto什么的都是坑
modulize才是王道
PS：话说final什么的可以标一标么

https://tieba.baidu.com/p/2207978953
↑

虚个蛋，mcf 一大堆 serializer 都是不虚的，只是包装了个虚的接口类，同时仍然提供非虚的接口。

我觉得不能，虚函数是一个动态概念，对a的解释只能是以ObjectInterface，真正调用运行的时候需要查询指向对象的虚表，然后才能得到函数入口地址。