小编cco*_*com的帖子

根据我的经验,有许多代码明确使用内联函数,这需要权衡:

1. 代码变得不那么简洁,而且可维护性稍差.
2. 有时,内联可以大大提高运行时性能.
3. 内联是在一个固定的时间点决定的,可能没有对其用途的非常好的预知,或者没有考虑所有(未来)周围环境.

问题是:链接时优化(例如,在GCC中)是否呈现手动内联,例如,在C99中声明一个"内联"函数并提供一个实现,已经过时了？我们是否真的不需要考虑自己内联大多数函数？那些总是从内联中受益的函数呢,例如deg_to_rad(x)？

澄清:我不是在考虑同一个翻译单元中的函数,而是考虑逻辑上应该存在于不同翻译单元中的函数.

更新:我经常看到反对"内联",并建议过时.但是,就个人而言,我确实经常看到明确的内联函数:作为类体中定义的函数.

比较C++中的虚函数和C中的虚拟表,一般编译器(以及足够大的项目)在虚拟化方面做得很好吗？

天真地看来,C++中的虚函数似乎有更多的语义,因此可能更容易虚拟化.

更新: Mooing Duck提到了内联的虚拟化功能.快速检查显示虚拟表的错过优化:

struct vtab {
    int (*f)();
};

struct obj {
    struct vtab *vtab;
    int data;
};

int f()
{
    return 5;
}

int main()
{
    struct vtab vtab = {f};
    struct obj obj = {&vtab, 10};

    printf("%d\n", obj.vtab->f());
}

我的GCC不会内联f,虽然它是直接调用的,即,虚拟化.C++中的等价物,

class A
{
public:
    virtual int f() = 0;
};

class B
{
public:
    int f() {return 5;}
};

int main()
{
    B b;
    printf("%d\n", b.f());
}

甚至内联f.所以C和C++之间存在第一个区别,尽管我不认为C++版本中添加的语义在这种情况下是相关的.

更新2:为了在C中进行虚拟化,编译器必须证明虚拟表中的函数指针具有特定值.为了在C++中进行虚拟化,编译器必须证明该对象是特定类的实例.在第一种情况下,证据似乎更难.但是,虚拟表通常仅在极少数地方进行修改,最重要的是:仅仅因为它看起来更难,并不意味着编译器不是那么好(否则你可能会认为xoring通常比添加两个更快)整数).