Matthew Austern
http://www.cuj.com/experts/1910/austern.htm?topic=experts
-----------------------------------------------------------------------------------------------------------------------
和 标准C++运行库中的绝大部分东西一样,标准容器类是用类型来参数化的:你能创建一个std::vector
不幸地是,虽然是常见技术,容纳指针的容器对新手来说也是造成混乱的最常见的根源之一。几乎没有哪个星期在C++新闻组中不出现这样的贴子的:为什么这样的代码导致内存泄漏:
{
std::vector
for (int i = 0; i < N; ++i)
v.insert(new my_type(i));
...
} // v is destroyed here
这个内存泄漏是编译器的bug吗?std::vector的析构函数不是会销毁v的元素的吗?
如 果你仔细想过std::vector
这篇文章解释了容纳指针的容器的行为是怎么样的,什么时候容纳指针的容器会有用,和在需要执行比标准容器在内存管理上的默认行更多的任务时,该做些什么。
标准容器使用值语义。举例来说,当你向一个vector附加一个变量x时:
v.push_back(x)
你实际正在做的是附加x 的一个拷贝。这个语句存储了x的值(的一个拷贝),而不是x的地址。在你将x加入一个vector后,你能对x做如何想做的事--比如赋给它一个新值或让 它离开生存域而销毁--而不影响vector中的拷贝。一个容器中的元素不能是另外一个容器的元素(两个容器的元素必须是不同的对象,即使这些元素碰巧相 等),并且将一个元素从容器中移除将会销毁这个元素(虽然具有相同的值的另外一个对象可能存在于别处)。最后,容器“拥有”它的元素:当一个容器销毁时, 其中的所以元素都随它一起销毁了。
这些特性与平常的内建数组很相似,并且可能是太明显了而不值一提。我列出它们以清楚显示容器和数组有多么相似。新手使用标准容器时发生的最常见的概念是认为容器“在幕后”做了比实际上更多的事。
值 语义不总是你所需要的:有时你需要在容器中存储对象的地址而不是拷贝对象的值。你能以和数组相同的方式,用容器实现引用语义:藉由显式要求。你能将任何类 型的对象放入容器[注1],而指针自己就是非常好的对象。指针占用内存;能被赋值;自己有地址;有能被拷贝的值。如果你需要存储对象的地址,就使用容纳指 针的容器。不再是写:
std::vector
my_type x;
...
v.push_back(x);
你能写:
std::vector
my_type x;
...
v.push_back(&x);
感觉上,没有任何变化。你仍然正在创建一个std::vector
拥有指针和拥有指针所指的东西之间的区别就象是vector与数组或局部变量。假如你写:
{
my_type* p = new my_type;
}
当 离开代码域时,指针p将会消失,但它所指向的对象,*p,不会消失。如果你想销毁这对象并释放其内存,你需要自己来完成,显式地写delete p或用其它等价的方法。 同样,在std::vector
你 可能奇怪为什么std::vector和其它标准容器没有设计得对指针做些特别的动作。首先,当然,有一个简单的一致性因素:理解有一致语义的库比理解有 许多特例的库容易。如果存在特例,很难划出分界线。你将iterator或用户自定义的handle类型等同于指针吗?如果在通用规则上对 vector
第 二,并且更重要的是:如果std::vector
想像一个特别的例子:
l 你正在维护一个任务链表,某些任务当前是活动的,某些被挂起。你用一个std::list
l 你的程序有一个字符串表:std::vector
l 你正在做I/O multiplexing,并且将一个std::vector
如果容纳指针的容器多手多脚地delete了所指向的对象,上面的用法没一个能成为可能。
如果你创建了一个容纳指针的容器,原因通常应该是所指向的对象由别处创建和销毁的。有没有情况是有理由获得一个容器,它拥有指针本身,还拥有所指向的对象?有的。我知道的唯一一个好的理由,但也是很重要的一个理由:多态。
C+ +中的多态是和指针/引用语义绑定在一起的。假如,举例来说,那个task不只是一个类,而且它是一个继承体系的基类。如果p是一个task *,那么p可能指向一个task对象或任何一个从task派生的类的对象。当你通过p调用task的一个虚函数,将会在运行期根据p所指向的实际类型调用 相应的函数。
不 幸地是,将task作为多态的基类意味着你不能使用vector
面向对象的设计通常意味着在对象被创建到对象被销毁之间,你通过指针或引用来访问对象。如果你想拥有一组对象,除了容纳指针的容器外,你几乎没有选择[注2]。管理这样的容器的最好的方法是什么?
如果你正使用容纳指针的容器来拥有一组对象,关键是确保所有的对象都被销毁。最明显的解决方法,可能也是最常见的,是在销毁容器前,遍历它,并为每个元素调用delete语句。如果手写这个循环太麻烦,很容易作一个包装:
template
class my_vector : private std::vector
{
typedef std::vector
public:
using Base::iterator;
using Base::begin;
using Base::end;
...
public:
~my_vector() {
for (iterator i = begin(); i != end(); ++i)
delete *i;
}
};
这个技巧能工作,但是它比看起来有更多的限制和要求。
问 题是,只改析构函数是不够的。如果你有一个列出所有的正要被销毁的对象的容器,那么你最好确保只要指针离开了容器那个对象就要被销毁,并且一个指针绝不在 容器中出现两次。当你用erase()或clear()移除指针时,必须要小心,但是你也需要小心容器的赋值和通过iterator的赋值:象v1 = v2,和v[n] = p这样的操作是危险的。标准泛型算法,有很多会执行通过iterator的赋值的,这是另外一个危险。你显然不能使用std::copy()和std:: replace()这样的泛型算法;稍微不太明显地,你也不能使用std::remove()、std::remove_if(),和std:: unique()[注3]。
象my_vector这样的包装类能够解决其中一些问题,但不是全部。很难看出如何阻止用户以危险的方式使用赋值,除非你禁止所有的赋值--而那时,你所得到的就不怎么象容器了。
问题是每个元素都必须被单独追踪,所以,也许解决方法是包装指针而不是包装整个容器。
标 准运行库定义了一个对指针包装的类std::auto_ptr
这是很自然的主意,但它是错误的。原因呢,再一次,是因为值语义。容器类假设它们能拷贝自己的元素。举例来说,如果你有一个vector
T t2(t1)
并且得到一个t1的拷贝t2。
形 式上,按C++标准中的说法,T要是Assignable的和CopyConstructible的。指针满足这些要求--你能得到指针的一个拷贝--但 auto_ptr不满足。auto_ptr的卖点是它维护强所用权,所以不允许拷贝。有一个形式上是拷贝构造函数的东西,但auto_ptr的“拷贝构造 函数”实际上并不进行拷贝。如果t1是一个 std::auto_ptr
std::auto_ptr
然后t2将不是t1的一个拷贝。不是进行拷贝,而是发生了所有权转移--t2得到了t1曾经有着的值,而t1被改成一个NULL指针。auto_ptr 的物件是脆弱的:你只不过看了它一下就能改变它的值。
在 某些实作上,当你试图创建一个vector
取代auto_ptr,你应该使用一个不同的“智能指针”,引用计数的指针类。带引用计数的指针跟踪多少个指针指向相同的对象。当你构造了一个引用计数指针的拷贝时,计数加1;当你销毁一个引用计数指针时,计数减1。当计数变成0时,指针所指的对象被自动销毁。
写 一个引用计数的指针类不是特别困难,但也不是几乎什么都不用做;达到线程安全需要特别的技巧。幸运地是,使用引用计数并不意味着你需要写一个自己的引用计 数指针类;几种这样的类已经存在并可免费使用。比如,你能使用Boost的shared_ptr类[注5]。我期望 shared_ptr或其它类似的东西将成为C++标准的下个修订版本的组成部分。
当 然,引用计数只是一种特别的垃圾回收。像所有形式的垃圾回收,它自动销毁你不再需要的对象。引用计数指针的主要优势是它们易于加入现有系统: share_ptr这样的机制只是一个小的单独的类,你能只在一个较大系统中某个部分中使用它。另一方面,引用计数是垃圾回收的一种最低效的形式(每个指 针的赋值和拷贝都需要一些相关的复杂处理),最没有柔性的形式(在两个数据结构拥有互指指针时,你必须小心)。其它形式的垃圾回收在C++程序中工作得同 样好。特别地,Boehm conservative garbage collector[注6]是免费的、可移植的,并被很好测试过。
如 果你使用一个保守的垃圾回收器,你只需要将它链接入程序就可以了。你不需要使用任何特别的指针包装类;只需要分配内存而不用关心delete它。特别地, 如果你创建一个vector
垃 圾回收的优势--无论是引用计数还是保守的垃圾回收器,或其它方法--是它让你将对象的生存期处理得完全不确定:你不须要掌握在某个特定时间程序的哪个部 份引用了这个对象。另一方面,垃圾回收的缺点也正是这一点!有时你确实知道对象的生存期,或至少知道在程序的某个特定状态结束后对象不应该继续存在。举例 来说,你可能创建了一个复杂的分析树;也许它填满了多态对象,也许它是太复杂而无法单独掌握每个节点,但是你能确定在分析完后就将不再需要它们中的任何一 个。
从手工管理的vetor
如果你的程序确实有明确定义的状态,那么你可能有理由期望在某个状态结束时销毁一组对象。代替垃圾回收,另外一个可选方法是通过一个arena(WQ注:字典上为“竞技场、舞台”之意,译不好,不译)来分配对象:维护一个对象列表,以便能一次就销毁所有对象。
你可能想知道这个技术和前面提到的技术(遍历容器并为每个元素调用destory())有多大差异。有实质性差异吗?如果没有,让我花了这么多时间的那些危险和限制,又怎么说?
差 异很小,但很重要:arena存储了一个对象集,目的是为了在以后delete它们,并且没有其它目的。它可以以标准容器的形式实现,但是它不暴露容器接 口。你在vector
arena 是个通用的主意。arena可能简单地是个容器,只要记住别使用不安全的成员函数,或者它可以是个包装类以试图运行得更安全。很多这样的包装类已经被写出 来了[注7]。Listing 1是一个arena类的简化例子,使用了一个实现上的技巧以使得不必为每个指针类型使用一个不同的arena类。举例来说,你可能写:
arena a;
...
std::vector
v.push_back(a.create
...
a.destroy_all();
我们几乎回到了起点:使用一个容纳指针的vector,所指向的对象由别处拥有和管理。
指针在C++程序中很常见,标准容器同样如此;不用惊奇,它们的组合物,容纳指针容器同样很常见。
新手最大的困难是容纳指针的容器时的所有权问题:应该什么时候delete所指向的对象?处理容纳指针的容器的绝大部分技术都可以归结到一个原则:如果你有一个容纳指针的容器,所指向的对象应该由其它地方所拥有。
l 如果正在处理非多态对象集(类型为my_type),你应该将对象的值存入容器,比如list
l 不要试图将auto_ptr放入标准容器。
l 如果有一组多态对象,你需要用容纳指针的容器来管理它们。(但是,那些指针可以被包装在某种handle类或智能指针类中。)当对象生存期不能预知时,或不重要时,最容易的方法是使用垃圾回收。垃圾回收的两个最简单的选择是引用计数指针类和保守的垃圾回收器。对你来说哪个是最佳选择取决于工具的可用性。
l 如果你有一组多态对象,并需要控制它们的生存期,最简单的方法是使用arena。一个简单的arena类例子展示于Listing 1。
#include
class arena {
private:
struct holder {
virtual ~holder() { }
};
template
struct obj_holder : public holder {
T obj;
template
obj_holder(Arg1 arg1)
: obj(arg1) { }
};
std::vector
private:
arena(const arena&);
void operator=(const arena&);
public:
arena() { }
~arena() {
destroy_all();
}
template
T* create(Arg1 arg1) {
obj_holder
owned.push_back(p);
return &p->obj;
}
void destroy_all() {
std::vector
while (i < owned.size()) {
delete owned[i];
++i;
}
owned.clear();
}
};
[1] Well, almost any: there are some restrictions — which will be discussed later — on the objects you put in a container. Most reasonable types conform to those restrictions; pointers certainly do.
[2] There is one sense in which you have a choice: you can simulate value semantics by hiding polymorphic pointers inside a non-polymorphic wrapper class. See, for example, James Coplien, Advanced C++ Programming Styles and Idioms (Addison-Wesley, 1991), for a discussion of this "envelope and letter" idiom. See also chapter 14 of Andrew Koenig and Barbara Moo's Accelerated C++ (Addison-Wesley, 2000), for a family of generic handle classes. However, while the envelope-and-letter idiom is useful, it is also fairly heavyweight and it will affect many aspects of your design. Unless you have other reasons for using an envelope-and-letter design, it would be silly to turn to it just for the sake of container classes.
[3] See Harald Nowak, "A remove_if for vector
[4] ?0.4.5, paragraph 3.
[5] <www.boost.org/libs/smart_ptr/shared_ptr.htm>.
[6] Hans-J. Boehm, "A garbage collector for C and C++," <www.hpl.hp.com/personal/Hans_Boehm/gc>.
[7] See, for example, Andrew Koenig, "Allocating C++ objects in clusters," Journal of Object-Oriented Programming, 6(3), 1993.