网站后台生成html,舆情报告范文,个体经营可以建设网站吗,大型网站建设规范缺省情况下C以by value方式#xff08;一个继承自C的方式#xff09;传递对象至#xff08;或来自#xff09;函数。除非你另外指定#xff0c;否则函数参数都是以实际实参的副本为初值#xff0c;而调用端所获得的亦是函数返回值的一个副本。这些副本系由对象的copy构造…缺省情况下C以by value方式一个继承自C的方式传递对象至或来自函数。除非你另外指定否则函数参数都是以实际实参的副本为初值而调用端所获得的亦是函数返回值的一个副本。这些副本系由对象的copy构造函数产出这可能使得pass-by-value成为昂贵的费时的操作。考虑以下class继承体系
class Person
{
public:Person(); // 为求简化省略参数virtual ~Person(); // 条款7告诉你为什么它是virtual// ...private:std::string name;std::string address;
};class Student : public Person
{
public:Student() // 再次省略参数~Student();// ...private:std::string schoolName;std::string schoolAddress;
};现在考虑以下代码其中调用函数validateStudent后者需要一个Student实参by value并返回它是否有效
bool validateStudent(Student s); // 函数以by value方式接受学生
Student plato; // 柏拉图苏格拉底的学生
bool platoIsOK validateStudent(plato); // 调用函数当上述函数被调用时发生什么事
无疑地Student的copy构造函数会被调用以plato为蓝本将s初始化。同样明显地当validateStudent返回s会被销毁。因此对此函数而言参数的传递成本是“一次Student copy构造函数调用加上一次Student析构函数调用”。
但那还不是整个故事。Student对象内有两个string对象所以每次构造一个Student对象也就构造了两个string对象。此外Student对象还继承自Person对象所以每次构造Student对象也必须构造出一个Person对象。一个Person对象又有两个string对象在其中因此每一次Person构造动作又需承担两个string构造动作。最终结果是以by value方式传递一个Student对象会导致调用一次Student copy构造函数、一次Person copy构造函数、四次string copy构造函数。当函数内的那个Student副本被销毁每一个构造函数调用动作都需要一个对应的析构函数调用动作。因此以by value方式传递一个Student对象总体成本是“六次构造函数和六次析构函数”
这是正确且值得拥有的行为毕竟你希望你的所有对象都能够被确实地构造和析构。但尽管如此如果有什么方法可以回避所有那些构造和析构动作就太好了。有的就是以pass by reference-to-const
bool validateStudent(const Student s);这种传递方式的效率高得多没有任何构造函数或析构函数被调用因为没有任何新对象被创建。修订后的这个参数声明中的const是重要的。原先的validateStudent以by value方式接受一个Student参数因此调用者知道他们受到保护函数内绝不会对传入的Student作任何改变validateStudent只能够对其副本做修改。现在Student以by reference方式传递将它声明为const是必要的因为不这样做的话调用者会忧虑validateStudent会不会改变他们传入的那个Student。
以by reference方式传递参数也可以避免slicing对象切割问题。当一个derived class对象以by value方式传递并被视为一个base class对象base class的copy构造函数会被调用而“造成此对象的行为像个derived对象”的那些特质全被切割掉了仅仅留下一个base class对象。这实在不怎么让人惊讶因为正是base class的构造函数建立了该对象。但这几乎绝不会是你想要的。假设你在一组class上工作用来实现一个图形窗口系统
class Window
{
public:// ...std::string name() const; // 返回窗口名称virtual void display() const; // 显示窗口和其内容
};class WindowWithScrollBars : public Window
{
public:// ...virtual void display() const;
};所有Window对象都带有一个名称你可以通过name函数取得它。所有窗口都可显示你可以通过display函数完成它。display是个virtual函数这意味简易朴素的base class Window对象的显示方式和华丽高贵的WindowWithScrollBars对象的显示方式不同见条款34和36。
现在假设你希望写个函数打印窗口名称然后显示该窗口。下面是错误示范
void printNameAndDisplay(Window w) // 不正确参数可能被切割
{std::cout w.name();w.display();
}当你调用上述函数并交给它一个WindowWithScrollBars对象会发生什么事呢
WindowWithScrollBars wwsb;
printNameAndDisplay(wwsb);参数w会被构造成为一个Window对象它是passed by value还记得吗而造成wwsb“之所以是个WindowWithScrollBars对象”的所有特化信息都会被切除。在printNameAndDisplay函数内不论传递过来的对象原本是什么类型参数w就像一个Window对象因为其类型是Window。因此在printNameAndDisplay内调用display调用的总是Window::display绝不会是WindowWithScrollBars::display。
解决切割slicing问题的办法就是以by reference-to-const的方式传递w
void printNameAndDisplay(const Window w) // 很好参数不会被切割
{std::cout w.name();w.display();
}现在传进来的窗口是什么类型w就表现出那种类型。
如果窥视C编译器的底层你会发现references往往以指针实现出来因此pass by reference通常意味真正传递的是指针。因此如果你有个对象属于内置类型例如intpass by value往往比pass by reference的效率高些。对内置类型而言当你有机会选择采用pass-by-value或pass-by-reference-to-const时选择pass-by-value并非没有道理。这个忠告也适用于STL的迭代器和函数对象因为习惯上它们都被设计为pass by value。迭代器和函数对象的实践者有责任看看它们是否高效且不受切割问题slicing problem的影响。这是“规则之改变取决于你使用哪一部分C见条款1”的一个例子。
内置类型都相当小因此有人认为所有小型type都是pass-by-value的合格候选人甚至它们是用户自定义的class亦然。这是个不可靠的推论。对象小并不意味其copy构造函数不昂贵。许多对象——包括大多数STL容器——内含的东西只比一个指针多一些但复制这种对象却需承担“复制那些指针所指的每一样东西”。那将非常昂贵。
即使小型对象拥有并不昂贵的copy构造函数还是可能有效率上的争议。某些编译器对待“内置类型”和“用户自定义类型”的态度截然不同纵使两者拥有相同的底层表述underlying representation。举个例子某些编译器拒绝把只由一个double组成的对象放进缓存器内却很乐意在一个正规基础上对光秃秃的double那么做。当这种事发生你更应该以by reference方式传递此等对象因为编译器当然会将指针reference的实现体放进缓存器内绝无问题。
“小型的用户自定义类型不必然成为pass-by-value优良候选人”的另一个理由是作为一个用户自定义类型其大小容易有所变化。一个type目前虽然小将来也许会变大因为其内部实现可能改变。甚至当你改用另一个C编译器都有可能改变type的大小。举个例子在作者下笔此刻某些标准程序库实现版本中的string类型比其他版本大七倍。
一般而言你可以合理假设“pass-by-value并不昂贵”的唯一对象就是内置类型和STL的迭代器和函数对象。至于其他任何东西都请遵守本条款的忠告尽量以pass-by-reference-to-const替换pass-by-value。
请记住 1.尽量以pass-by-reference-to-const替换pass-by-value。前者通常比较高效并可避免切割问题。
2.以上规则并不适用于内置类型以及STL的迭代器和函数对象。对它们而言pass-by-value往往比较适当。
