关于内联的一个小问题

2003-03-27 09:39:20 101 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

基于pytest+Allure+Python+CANoe的汽车诊断自动化测试框架搭建实战自动化测试是提升软件质量和研发效率的关键技术，其核心原理是通过脚本模拟人工操作，实现测试用例的自动执行与结果验证。在汽车电子领域，诊断服务测试是确保车辆ECU（电子控制单元）功能正常的重要环节，传统手动测试在面对海量用例和频繁回归时效率低下。本文聚焦于如何利用Python的pytest测试框架、Allure报告工具以及Excel数据驱动，构建一个与Vector CANoe仿真测试环境深度集成的自动化测试解决方案。该方案通过Python调用CANoe的COM接口，实现了诊断报文的自动发送与响应验证，并结合Al 阅读详情

将虚函数同时申明为内联函数，在使用时会不会产生问题？？

...全文

Windows NPS与华为、华三、思科设备RADIUS认证实战指南本文详细介绍了Windows NPS与华为、华三、思科设备RADIUS认证的实战配置指南。通过NPS服务器统一管理网络设备认证，实现企业级安全访问控制，涵盖基础配置、设备对接及故障排查方法，助力管理员提升网络安全管理效率。阅读详情

haojun80

C语言 70,039 成员 243,237 内容

+ 关注 + 加入社区

切换为时间正序

alphax 2003-03-29

打赏
举报

mark

bigkahuna 2003-03-28

打赏
举报

内联函数越短越好，如果类中的内联函数过长代码的可读性不好

kicool 2003-03-28

打赏
举报

<< Effective C++>>
条款33: 明智地使用内联

内联函数------多妙的主意啊！它们看起来象函数，运作起来象函数，比宏(macro)要好得多（参见条款1），使用时还不需要承担函数调用的开销。你还能对它们要求更多吗？

然而，你从它们得到的确实比你想象的要多，因为避免函数调用的开销仅仅是问题的一个方面。为了处理那些没有函数调用的代码，编译器优化程序本身进行了专门的设计。所以当内联一个函数时，编译器可以对函数体执行特定环境下的优化工作。这样的优化对"正常"的函数调用是不可能的。

我们还是不要扯得太远。程序世界和现实生活一样，从来就没有免费的午餐，内联函数也不例外。内联函数的基本思想在于将每个函数调用以它的代码体来替换。用不着统计专家出面就可以看出，这种做法很可能会增加整个目标代码的体积。在一台内存有限的计算机里，过分地使用内联所产生的程序会因为有太大的体积而导致可用空间不够。即使可以使用虚拟内存，内联造成的代码膨胀也可能会导致不合理的页面调度行为（系统颠簸），这将使你的程序运行慢得象在爬。（当然，它也为磁盘控制器提供了一个极好的锻炼方式:)）过多的内联还会降低指令高速缓存的命中率，从而使取指令的速度降低，因为从主存取指令当然比从缓存要慢。

另一方面，如果内联函数体非常短，编译器为这个函数体生成的代码就会真的比为函数调用生成的代码要小许多。如果是这种情况，内联这个函数将会确实带来更小的目标代码和更高的缓存命中率！

要牢记在心的一条是，inline指令就象register，它只是对编译器的一种提示，而不是命令。也就是说，只要编译器愿意，它就可以随意地忽略掉你的指令，事实上编译器常常会这么做。例如，大多数编译器拒绝内联"复杂"的函数（例如，包含循环和递归的函数）；还有，即使是最简单的虚函数调用，编译器的内联处理程序对它也爱莫能助。（这一点也不奇怪。virtual的意思是"等到运行时再决定调用哪个函数"，inline的意思是"在编译期间将调用之处用被调函数来代替"，如果编译器甚至还不知道哪个函数将被调用，当然就不能责怪它拒绝生成内联调用了）。以上可以归结为：一个给定的内联函数是否真的被内联取决于所用的编译器的具体实现。幸运的是，大多数编译器都可以设置诊断级，当声明为内联的函数实际上没有被内联时，编译器就会为你发出警告信息（参见条款48）。

假设写了某个函数f并声明为inline，如果出于什么原因，编译器决定不对它内联，那将会发生些什么呢？最明显的一个回答是将f作为一个非内联函数来处理：为f生成代码时就象它是一个普通的"外联"函数一样，对f的调用也象对普通函数调用那样进行。

理论上来说确实应该这样发生，但理论和现实往往会偏离，现在就属于这种情况。因为，这个方案对解决"被外联的内联"（outlined inline）这一问题确实非常理想，但它加入到C++标准中的时间相对较晚。较早的C++规范（比如ARM------参见条款50）告诉编译器制造商去实现的是另外不同的行为，而且这一旧的行为在现在的编译器中还很普遍，所以必须理解它是怎么一回事。

稍微想一想你就可以记起，内联函数的定义实际上都是放在头文件中。这使得多个要编译的单元（源文件）可以包含同一个头文件，共享头文件内定义的内联函数所带来的益处。下面给出了一个例子，例子中的源文件名以常规的".cpp"结尾，这应该是C++世界最普遍的命名习惯了：

// 文件example.h
inline void f() { ... } // f的定义

...

// 文件source1.cpp
#include "example.h" // 包含f的定义

... // 包含对f的调用

// 文件source2.cpp
#include "example.h" // 也包含f的定义

... // 也调用f
假设现在采用旧的"被外联的内联"规则，而且假设f没有被内联，那么，当source1.cpp被编译时，生成的目标文件中将包含一个称为f的函数，就象f没有被声明为inline一样。同样地，当source2.cpp被编译时，产生的目标文件也将包含一个称为f的函数。当想把两个目标文件链接在一起时，编译器会因为程序中有两个f的定义而报错。

为了防止这一问题，旧规则规定，对于未被内联的内联函数，编译器把它当成被声明为static那样处理，即，使它局限于当前被编译的文件。具体到刚才看到的例子中，遵循旧规则的编译器处理source1.cpp中的f时，就象f在source1.cpp中是静态的一样；处理source2.cpp中的f时，也把它当成在source2.cpp中是静态的一样。这一策略消除了链接时的错误，但带来了开销：每个包含f的定义（以及调用f）的被编译单元都包含自己的f的静态拷贝。如果f自身定义了局部静态变量，那么，每个f的拷贝都有此局部变量的一份拷贝，这必然会让程序员大吃一惊，因为一般来说，函数中的"static"意味着"只有一份拷贝"。

具体实现起来也会令人吃惊。无论新规则还是旧规则，如果内联函数没被内联，每个调用内联函数的地方还是得承担函数调用的开销；如果是旧规则，还得忍受代码体积的增加，因为每个包含（或调用） f的被编译单元都有一份f的代码及其静态变量的拷贝！（更糟糕的是，每个f的拷贝以及每个f的静态变量的拷贝往往处于不同的虚拟内存页面，所以两个对f的不同拷贝进行调用有可能导致多个页面错误。）

还有呢！有时，可怜的随时准备为您效劳的编译器即使很想内联一个函数，却不得不为这个内联函数生成一个函数体。特别是，如果程序中要取一个内联函数的地址，编译器就必须为此生成一个函数体。编译器怎么能产生一个指向不存在的函数的指针呢？

inline void f() {...} // 同上
void (*pf)() = f; // pf指向f
int main()
{
f(); // 对f的内联调用
pf(); // 通过pf对f的非内联调用
...
}
这种情况似乎很荒谬：f的调用被内联了，但在旧的规则下，每个取f地址的被编译单元还是各自生成了此函数的静态拷贝。（新规则下，不管涉及的被编译单元有多少，将只生成唯一一个f的外部拷贝）

即使你从来不使用函数指针，这类"没被内联的内联函数"也会找上你的门，因为不只是程序员会使用函数指针，有时编译器也这么做。特别是，编译器有时会生成构造函数和析构函数的外部拷贝，这样就可以通过得到那些函数的指针，方便地构造和析构类的对象数组（参见条款M8）。

实际上，随便一个测试就可以证明构造函数和析构函数常常不适合内联；甚至，情况比测试结果还糟。例如，看下面这个类Derived的构造函数：

class Base {
public:
...
private:
string bm1, bm2; // 基类成员1和2
};
class Derived: public Base {
public:
Derived() {} // Derived的构造函数是空的，
... // ------但，真的是空的吗？
private:
string dm1, dm2, dm3; // 派生类成员1-3
};
这个构造函数看起来的确象个内联的好材料，因为它没有代码。但外表常常欺骗人！仅仅因为它没有代码并不能说明它真的不含代码。实际上，它含有相当多的代码。

C++就对象创建和销毁时发生的事件有多方面的规定。条款5和M8介绍了当使用new时，动态创建的对象怎样自动地被它们的构造函数初始化，以及当使用delete时析构函数怎样被调用。条款13说明了当创建一个对象时，对象的每个基类以及对象的每个数据成员会被自动地创建；当对象被销毁时，会自动地执行相反的过程（即析构）。这些条款告诉你，C++规定了哪些必须发生，但没规定"怎么"发生。"怎么发生"取决于编译器的实现者，但要弄清楚的是，这些事件不是凭空自己发生的。程序中必然有什么代码使得它们发生，特别是那些由编译器的实现者写的、在编译其间插入到你的程序中的代码，必然也藏身于某个地方------有时，它们就藏身于你的构造函数和析构函数。所以，对于上面那个号称为空的Derived的构造函数，有些编译器会为它产生相当于下面的代码：

// 一个Derived构造函数的可能的实现
Derived::Derived()
{
// 如果在堆上创建对象，为其分配堆内存；
// operator new的介绍参见条款8
if (本对象在堆上)
this = ::operator new(sizeof(Derived));
Base::Base(); // 初始化Base部分
dm1.string(); // 构造dm1
dm2.string(); // 构造dm2
dm3.string(); // 构造dm3
}
别指望上面这样的代码可以通过编译，因为它在C++中是不合法的。首先，在构造函数内无法知道对象是不是在堆上。（想知道如何可靠地确定一个对象是否在堆上，请参见条款M27）另外，对this赋值是非法的。还有，通过函数调用访问构造函数也是不允许的。然而，编译器工作起来没这些限制，它可以随心所欲。但代码的合法性不是现在要讨论的主题。问题的要点在于，调用operator new（如果需要的话）的代码、构造基类部分的代码、构造数据成员的代码都会神不知鬼不觉地添加到你的构造函数中，从而增加构造函数的体积，使得构造函数不再适合内联。当然，同样的分析也适用于Base的构造函数，如果Base的构造函数被内联，添加到它里面的所有代码也会被添加到Derived的构造函数（Derived的构造函数会调用Base的构造函数）。如果string的构造函数恰巧也被内联，Derived的构造函数将得到其代码的5个拷贝，每个拷贝对应于Derived对象中5个string中的一个（2个继承而来，3个自己声明）。现在你应该明白，内联Derived的构造函数并非可以很简单就决定的！当然，类似的情况也适用于Derived的析构函数，无论如何都要清楚这一点：被Derived的构造函数初始化的所有对象都要被完全销毁。刚被销毁的对象以前可能占用了动态分配的内存，那么这些内存还需要释放。

程序库的设计者必须预先估计到声明内联函数带来的负面影响。因为想对程序库中的内联函数进行二进制代码升级是不可能的。换句话说，如果f是

jakenIT 2003-03-28

打赏
举报

我有Effective C++和Effective&More Effective C++这两本书的电子版。发放共享。
QQ:86950649

yuanhen 2003-03-28

打赏
举报

同意Jinglihui(雪狐) 和楼上

greening 2003-03-28

打赏
举报

同意Jinglihui(雪狐)
内联是以代码膨胀（复制）为代价，仅仅省去了函数调用的开销，从而提高函数的执行效率。如果执行函数体内代码的时间，相比于函数调用的开销较大，那么效率的收获会很少。另一方面，每一处内联函数的调用都要复制代码，将使程序的总代码量增大，消耗更多的内存空间

Meyer 2003-03-28

打赏
举报

虚函数的作用表现在运行期，
inline 是编译器在代码上做文章。
所以 inline 虚函数是没有意义的。
但编译器不会说这是错误。

然因,我想可能是这样。
在类体内定义的函数是默认inline 的，如果编译器说 inline 虚函数是错误。
那么，意味着我们的虚函数不能在类体内定义，这个要求岂不是龌龊?

TopCat 2003-03-27

打赏
举报

是的。

Effective C++的介绍：
http://www.china-pub.com/computers/common/info.asp?id=3564

haojun80 2003-03-27

打赏
举报

你的意思是说虽然编译时可以通过，但实际上inline并不起作用？？？

能介绍一下《Effective C++》这本书吗？？

Jinglihui 2003-03-27

打赏
举报

inline指示对编译器来说只是一个建议,编译器可以选择忽略该建议,因为把一个函数声明为inline函数,并不见得真的适合在调用点上展开.
一般地,inline机制用来优化小的、只有几行的、经常调用的函数!

TopCat 2003-03-27

打赏
举报

可以，但是虚函数不会被inlined。

见《Effective C++》item 33

关于内联的一个小问题

相关推荐