effective C++ 条款 20:宁以pass-by-reference-to-const替换pass-by-value

缺省情况下c++以by value 的方式传递对象(或来自)函数。函数参数是以实参的副本为初值,用函数获得的也是函数返回值的一个副本

这些副本由对象的copy构造函数产出,这可能使得pass-by-value成为昂贵的操作:

class Person
{
public:
    Person();
    virtual ~Person();
protected:
private:
    std::string name;
    std::string address;
};

class Student : public Person{
public:
    Student();
    ~Student();
private:
    std::string schoolName;
    std::string schoolAddress;
};

bool validateStudent(Student s);
Student plato;
bool platoIsOK = validateStudent(plato);

当上述函数调用validateStudent(plato);时,Student的copy构造函数被调用,以plato为蓝本将s初始化。当validateStudent返回s被销毁。所以参数的传递成本是“一次Student copy构造函数调用,一次Student析构函数调用”。

但是还不是整个故事,Student对象内有两个string对象,Student对象继承自Person对象,因此必须构造出Person对象,Person对象又有两个string在其中。

因此以by-value方式传递一个Student对象会导致调用一次Student copy构造函数、一次Person copy构造函数、四次string copy构造函数。当那个Student复件被销毁,每个构造函数动作多需要一个对应的析构函数调用动作。所以总体成本是“六次构造函数和六次析构函数”!

回避这些构造和析构的方法就是pass-by-reference-to-const

bool validateStudent(const Student& s);

这种方式没有任何构造和析构函数被调用,因为没有任何新对象被创建。const是必要的,调用者不用担心validateStudent改变他们传入的那个Student。

by reference传递参数还可以避免slicing(对象切割)问题。当一个derived class对象以by value传递给一个base class对象,

base class的copy构造函数被调用,而“构造此对象的行为像个derived class对象”的那些特化性质被切割掉了,仅留下一个base class对象。

class Window
{
public:
    std::string name() const;
    virtual void display() const;
};

class WindowWithScrollBars : public Window
{
public:
    virtual void display() const;
};

void printNameAndDisplay(Window w)
{
    std::cout << w.name();
    w.display();
}

WindowWithScrollBars wwsb;
printNameAndDisplay(wwsb);

w会被构造成一个Window对象:他是pass-by-value,造成wwsb“之所以是个WindowWithScrollBars对象”的所有特化信息被切除。所以display调用的总是Window::display()。

解决切割的方法,就是以by reference to const的方式传递w:

void printNameAndDisplay(const Window& w)
{
std::cout << w.name();
w.display();
}

窥视c++编译器的底层,你会发现,reference往往以指针实现出来,因此pass-by-reference通常意味着传递的是指针。因此如果

你有个对象属于内置类型(例如int)pass by value往往比pass by reference的效率要高些。这个忠告也适用于stl的迭代器函数对象,因此它们习惯上被设计为pass by value。实践者有责任看看它们是否高效且不受切割问题的影响。

小型的用户自定义类型

1,其大小容易有所变化。将来也许会变化

2,某些编译器对待“内置类型”和“用户自定义类型”截然不同,纵使两者有相同的底层表述。

posted @ 2012-01-17 16:04  lidan  阅读(499)  评论(0编辑  收藏  举报