尽量使用“引用常量”传递函数参数

本文探讨了C++中函数参数传递的方式及其性能影响。强调了对于类对象,使用引用常量传递比值传递更高效;而对于内置类型、STL迭代器及函数对象,则推荐值传递。文章还讨论了不同传递方式对编译器优化的影响。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

默认情况下, C++ 为函数传入和传出对象是采用传值方式的(这是由 C语言继承而来的特征)。除非你明确使用其他方法,函数的形式参数总会通过复制实在参数的副本来创建,并且,函数的调用者得到的也是函数返回值得一个副本。这些副本是由对象的拷贝构造函数创建的。这使得“传值”成为一项代价十分昂贵的操作。

下面向你介绍正确的方法,那就是:通过引用常量传递参数: bool (const Student&s);  这里Student是一个类名。
这 样做效率会提高很多:由于不会创建新的对象,所以就不会存在构造函数或析构函数的调用。改进的参数表中的const 是十分重要的:Student 对象是以引用形式传入的,有必要将其声明为 const 的,因为如果不这样,调用者就需要关心传入的 Student 对象有可能会被修改。

揭 开 C++ 编译器的面纱,你将会发现引用通常情况下是以指针的形式实现的,所以通过引用传递通常意味着实际上是在传递一个指针。因此,如果传递一个内建数据类型的对象(比如 int ),传值会被传递引用更为高效。那么,对于内建数据类型,当你在传值和传递常量引用之间徘徊时,传值方式不失为一个更好的选择。迭代器和 STL 中的函数对象都是如此,这是因为它们设计的初衷就是更适于传值,这是C++ 的惯例。实现迭代器和函数对象的人员有责任考虑复制时的效率问题和截断问题.

内建数据类型体积较小,所以一些人得出这样的结论:所有体积较小的类型都适合使用传值,即使它们是用户自定义的。这是一个不可靠的推理。仅仅通过一 个对象体积小并不能判定调用它的拷贝构造函数的代价就很低。许多对象——包括大多数 STL 容器——其中仅仅包含一个指针和很少量的其它内容,但是复制这样的对象的同时,它所指向的所有内容都需要复制。这将会是一件十分昂贵的事情。

即 使体积较小的对象的拷贝构造函数不会带来昂贵的开销,它也会引入性能问题。一些编译器对内建数据类型和用户自定义数据类型是分别对待的,即使它们的原始表示方式完全相同。比如说一些编译器很乐意将一个单纯的 double 值放入寄存器中,这是语言的常规,但将仅包含一个 double 值的对象放入寄存器时,编译器就会报错了。当你遇到这种事情时,你可以使用引用传递这类对象,因为编译器此时一定会将指针(引用的具体实现)放入寄存器中。

小型用户自定义数据类型不适用于传值方式还有一个理由,那就是:作为用户自定义类型,它们的大小并不是固定的。现在很小的类型在未 来的版本中可能会变得很大,这是因为它的内部实现方式可能会改变。即使是你更改了 C++ 语言的具体实现都可能会影响到类型的大小。比如,在我编写上面的示例的时候,一些对标准库中 string 实现的大小竟然达到了另一些的七倍。

总体上讲,只有内建数据类型、 STL 迭代器和函数对象类型适用于传值方式。对于所有其它的类型,都应该遵循本条款中的建议:使用引用常量传参,而不是传值。

牢记在心 :

尽量使用引用常量传参,而不是传值方式。因为传引用更高效,而且可以避免“截断问题”。
对于内建数据类型、 STL 迭代和函数对象类型,这一规则就不适用了,对它们来说通常传值方式更实用。

 

参考资料: 《Effective c++

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值