Effective STL 条款3

原创 2003年12月23日 13:48:00

条款3:使容器里对象的拷贝操作轻量而正确

容器容纳了对象,但不是你给它们的那个对象。此外,当你从容器中获取一个对象时,你所得到的对象不是容器里的那个对象。取而代之的是,当你向容器中添加一个对象(比如通过insert或push_back等),进入容器的是你指定的对象的拷贝。当你从容器中获取一个对象时(比如通过front或back),你取到的是容器中那个对象的拷贝。拷进去,拷出来。这就是STL的方式。

一旦一个对象进入一个容器,以后对它的拷贝并不少见。如果你从vector、string或deque中插入或删除了什么,现有的容器元素会移动(拷贝)(参见条款514)。如果你使用了任何排序算法(参见条款31):next_permutation或者previous_permutation;remove、unique或它们的同类(参见条款32);rotate或reverse等,对象会移动(拷贝)。是的,拷贝对象是STL的方式。

你可能会对所有这些拷贝是怎么完成的感兴趣。这很简单,一个对象通过使用它的拷贝成员函数来拷贝,特别是它的拷贝构造函数和它的拷贝赋值操作符(很好的名字,不是吗?)。对于用户自定义类,比如Widget,这些函数传统上是这么声明的:

class Widget { 
public: 
 ... 
 Widget(const Widget&);  // 拷贝构造函数
 Widget& operator=(const Widget&); // 拷贝赋值操作符
  ... 
};

如果你自己没有声明这些函数,你的编译器始终会为你声明它们。拷贝内建类型(比如ing、指针等)也始终是通过简单地拷贝他们的内在比特来完成的。(有关拷贝构造函数和赋值操作符的详细情况,请参考任何C++的介绍性书籍。在《Effective C++》中,条款11和27专注于这些函数的行为。)

因为会发生所有这些拷贝,本条款的动机现在就很清楚了。如果你用一个拷贝过程很昂贵对象填充一个容器,那么一个简单的操作——把对象放进容器也会被证明为是一个性能瓶颈。容器中移动越多的东西,你就会在拷贝上浪费越多的内存和时钟周期。此外,如果你有一个非传统意义的“拷贝”的对象,把这样的对象放进容器总是会导致不幸。(会导致的不幸之一的例子请看条款8。)

当然由于继承的存在,拷贝会导致分割(slice)。那就是说,如果你以基类对象建立一个容器,而你试图插入派生类对象,那么当对象(通过基类的拷贝构造函数)拷入容器的时候对象的派生部分会被删除:

vector<Widget> vw; 
class SpecialWidget: // SpecialWidget从上面的Widget派生
public Widget {...};
SpecialWidget sw; 
vw.push_back(sw);  // sw被当作基类对象拷入vw
   // 当拷贝时它的特殊部分丢失了

分割问题暗示了把一个派生类对象插入基类对象的容器几乎总是错的。如果你希望结果对象表现为派生类对象,比如,调用派生类的虚函数等,总是错的。(关于分割问题更多的背景知识,请参考《Effective C++》条款22。它会在STL中发生的另一个例子,参见条款38。)

一个使拷贝更高效、正确而且对分割问题免疫的简单的方式是建立指针的容器而不是对象的容器。也就是说,不是建立一个Widget的容器,建立一个Widget*的容器。拷贝指针很快,它总是严密地做你希望的(指针拷贝比特),而且当指针拷贝时没有分割。不幸的是,指针的容器有它们自己STL相关的头疼问题。你可以从条款733了解它们。如果你想避免这些头疼并且仍要避开效率、正确性和分割问题,你可能会发现智能指针的容器是一个吸引人的选择,请转到条款7

如果所有这些使STL的拷贝机制听起来很疯狂,就请重新想想。是,STL进行了大量拷贝,但它通常设计为避免不必要的对象拷贝,实际上,它也被实现为避免不必要的对象拷贝。和C和C++内建容器的行为做个对比,下面的数组:

Widget w[maxNumWidgets];  // 建立一个大小为maxNumWidgets的Widgets数组
    // 默认构造每个元素

即使我们一般只使用其中的一些或者我们立刻使用从某个地方获取(比如,一个文件)的值覆盖每个默认构造的值,这也得构造maxNumWidgets个Widget对象。使用STL来代替数组,你可以使用一个可以在需要的时候增长的vector:

vector<Widget> vw;   // 建立一个0个Widget对象的vector
    // 需要的时候可以扩展

我们也可以建立一个可以足够包含maxNumWidgets个Widget的空vector,但没有构造Widget:

vector<Widget> vw; 
vw.reserve(maxNumWidgets);  // reserve的详细信息请参见条款14

和数组对比,STL容器更文明。它们只建立(通过拷贝)你需要的个数的对象,而且它们只在你指定的时候做。是的,我们需要知道STL容器使用了拷贝,但是别忘了一个事实:比起数组它们仍然是一个进步。

effective stl 第19条:理解相等(equality)和等价(equivalence)的区别

#include #include #includeusing namespace std;bool ciStringCompare(const string l, const string r) {...
  • u014110320
  • u014110320
  • 2016年09月20日 23:36
  • 236

《Effective C++》设计与声明:条款18-条款19

这两个条款讲的是:接口的设计和类的设计。其中接口的设计原则是让接口容易被正确使用,不容易被误用;后面有一系列的做法。类的设计,讲的是类设计犹如新类型type的设计。在设计类时要考虑的一系列问题。...
  • KangRoger
  • KangRoger
  • 2015年01月21日 21:43
  • 1317

《Effective C++》学习笔记——条款31

《Effective C++》学习笔记——条款31:将文件间的编译依存关系降至最低
  • lx417147512
  • lx417147512
  • 2015年06月15日 13:51
  • 1362

《Effective C++》学习笔记——条款25

《Effective C++》学习笔记——条款25:考虑写出一个不抛异常的 swap 函数
  • lx417147512
  • lx417147512
  • 2014年12月30日 22:32
  • 835

《Effective C++》:条款41-条款42

条款41了解隐式接口和编译期多态 条款42了解typename的双重意义条款
  • KangRoger
  • KangRoger
  • 2015年03月10日 22:13
  • 1197

《Effective C++》:条款28-条款29

条款28避免返回handles指向对象内部成分:指的是不能返回对象内部数据/函数的引用、指针等。 条款29为异常安全而努力是值得的:指的是要有异常处理机制,避免发生异常时造成资源泄露等问题。...
  • KangRoger
  • KangRoger
  • 2015年02月19日 19:47
  • 1366

《Effective C++》资源管理:条款13-条款15

在系统中,资源是有限的,一旦用完必须归还给系统,否则可能会造成资源耗尽或其他问题。例如,动态分配的内存如果用完不释放会造成内存泄漏。 这里说的资源不仅仅是指内存,还包括其他,例如文件描述符、网络连接、...
  • KangRoger
  • KangRoger
  • 2015年01月14日 21:46
  • 1278

《Effective C++》让自己习惯C++:条款1-条款4

《Effective C++》条款1到条款4。基本是总结C++的一些特点,尤其是不同于C语言的特点。...
  • KangRoger
  • KangRoger
  • 2014年12月13日 19:26
  • 2344

Effective Modern C++ 条款28 理解引用折叠

Effective Modern C++ 条款28
  • big_yellow_duck
  • big_yellow_duck
  • 2016年09月04日 19:34
  • 1978

《Effective C++》:条款44-条款45

条款44将与参数无关的代码抽离templates 条款45运用成员函数模板接受所有兼容类型...
  • KangRoger
  • KangRoger
  • 2015年03月12日 22:01
  • 1480
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Effective STL 条款3
举报原因:
原因补充:

(最多只允许输入30个字)