揭开 C++ 编译器的面纱，你将会发现引用通常情况下是以指针的形式实现的，所以通过引用传递通常意味着实际上是在传递一个指针。因此，如果传递一个内建数据类型的对象（比如 int ），传值会比传递引用更为高效。那么，对于内建数据类型，当你在传值和传递常量引用之间徘徊时，传值方式不失为一个更好的选择。迭代器 和 STL 中的函数对象都是如此，这是因为它们设计的初衷就是更适于传值，这是 C++ 的惯例。实现迭代器和函数对象的人员有责任考虑复制时的效率问题和截断问题。（这就是一个“使用哪种规则，取决于当前使用哪一部份的 C++ ”，参见第 1 条）
内建数据类型体积较小，所以一些人得出这样的结论：所有体积较小的类型都适合使用传值，即使它们是用户自定义的。这是一个不可靠的推理。仅仅通过一个对象体积小并不能判定调用它的拷贝构造函数的代价就很低。许多对象——包括大多数 STL 容器——其中仅仅包含一个指针和很少量的其它内容，但是复制这样的对象的同时，它所指向的所有内容都需要复制。这将会是一件十分昂贵的事情。
即使体积较小的对象的拷贝构造函数不会带来昂贵的开销，它也会引入性能问题。一些编译器对内建数据类型和用户自定义数据类型是分别对待的，即使它们的原始表示方式完全相同。比如说一些编译器很乐意将一个单纯的 double 值放入寄存器中，这是语言的常规，但将仅包含一个 double 值的对象放入寄存器时，编译器就会报错了。当你遇到这种事情时，你可以使用引用传递这类对象，因为编译器此时一定会将指针（引用的具体实现）放入寄存器中。
小型用户自定义数据类型不适用于传值方式还有一个理由，那就是：作为用户自定义类型，它们的大小并不是固定的。现在很小的类型在未来的版本中可能会变得很大，这是因为它的内部实现方式可能会改变。即使是你更改了 C++ 语言的具体实现都可能会影响到类型的大小。比如，在我编写上面的示例的时候，一些对标准库中 string 实现的大小竟然达到了另一些的七倍。
总体上讲，只有内建数据类型、 STL 迭代器和函数对象类型适用于传值方式。对于所有其它的类型，都应该遵循本条款中的建议：使用引用常量传参，而不是传值。
牢记在心
- 尽量使用引用常量传参，而不是传值方式。因为传引用更高效，而且可以避免“截断问题”。
- 对于内建数据类型、 STL 迭代和函数对象类型，这一规则就不适用了，对它们来说通常传值方式更实用。