容器在STL中被认为是智能的。它们支持向前和向后的迭代器;它们能告诉你它所保存的对象类型(通过typedef value_type);在插入和删除过程中它们进行了良好的内存管理;它们将报告自己包含了多少对象和自己最多能包含多少对象(分别通过size和max_size取得);并且,当容器销毁时,它自动销毁每个被包含的对象。

  拥有如此聪明的容器,许多程序员自己不再担心清理问题。他们认为容器会为他们操心。多数情况下,他们正确,但是当容器包括由new生产对象指针时,他们就不是太正确。毫无疑问,指针容器在销毁时,会销毁它所包容的每一个元素,但是指针的“析构函数”只是一个空操作。它不会调用delete。

  结果是,以下代码直接导致内存资源泄漏:

void doSomething()

{

vector<Widget*> vwp;

for (int i = 0; i < SOME_MAGIC_NUMBER; ++i)

vwp.push_back(new Widget);

… // use vwp

} //Widgets are leaked here!

  当离开vwp的作用范围时,vwp的每一个元素都会被销毁,但是这并不改变new所产生的对象没有被delete这个事实。这个删除动作是程序员的责任,而不是vector的。这其实是一个功能,因为只有程序员才知道指针是否需要删除。

  通常,程序员希望它们那样(删除指针)。在那种情况(上例)中,使它发生其实很简单。

void doSomething()

{

vector<Widget*> vwp;

… // as before

for (vector<Widget*>::iterator i = vwp.begin();i != vwp.end(),++i) {

delete *i;

}

  这能行,如果你不是十分在意它只是“能行”。问题之一是新的for循环做了很多for_each做的事,但它不像for_each一样清析。另一个问题是代码不是异常安全。如果一个异常在vwp填上指针之后,而这些指针还没有删除之前被抛出。资源泄漏再次出现。幸运的是两个问题都可以克服。

  修改for_each类似的代码以使用真正的for_each,需要将delete操作置于(仿)函数对象中。这像一个儿童游戏,假设你有一个喜欢与STL一起玩游戏的小孩。

template<typename T>

struct DeleteObject:                  // Item 40 describes why

public unary_function<const T*, void> { //this inheritance is here

 

void operator()(const T* ptr) const

delete ptr;

}

};

  现在你可以这样做:

void doSomething()

{

… // as before

for_each(vwp.begin(), vwp.end(), DeleteObject<Widget>);

}

  不太走运,它要求指明DeleteObject删除的对象类型(这里是:Widget )。令人讨厌,vwp是一个vector<Widget*>,因此DeteleObject删除的当然是Widget指针!这种冗余不只是令人讨厌,因为它可能导致难以检查的bug出现。试想一下,例如,有人故意决定要从string继承:

class SpecialString: public string { ...};

  这是一种危险的产物,因为string与其它标准STL容器一样,没有virtual析构函数。公有继承一个没有虚析构函数的对象是C++一个主要的误区(a major C++ no-no)(近一步的细节,在任何一个很好的C++书中都有讨论。在Effective C++中,它被放在Item 14)。不论如何,有人如此作了。考虑一下以下代码的行为:

void doSomething()

{

deque<SpecialString*> dssp;

for_each( dssp.begin(), dssp.end(), // undefined behavior! Deletion

DeleteObject<string>()); //of a derived object via a base

} // class pointer where there is

//no virtual destructor

  注意dssp声明为保存SpecialString的指针,但是for_each循环的作者告诉DeleteObject,它准备删除string的指针。很容易发现什么样的错误会发生。SpecialString无疑在很大程度上表现为string。因此有人会忘记它的用户,他们会不记得他们使用的是SpecialString而不是string。

  可以排除这个错误(也可以减少DeleteObject用户敲打键盘的次数)使用编译器推绎出传给DeleteObject::operator()的指针类型。所有工作只是把模板从DeleteObject类移到operator()上。

struct DeleteObject { // templatization and base

// class removed here

template<typename T> II templatization added here

void operator()(const T* ptr) const

{

delete ptr;

}

}

  编译器知道传递给DeleteObject::operator()的指针类型,因此它将自动为该类型指针生成一个operator的实例。这种类型推绎的产生,取决于我们放弃DeleteObject的可适应性。考虑一下DeleteObject被设计为如何使用,就很难找出可能发生问题的地方。

  使用这一新版的DeleteObject,SpecialString客户的代码看起来像这样:

void doSomething()

{

deque<SpecialString*> dssp;

for_each( dssp.begin(), dssp.end(),

DeleteObject ()); // ah! well-defined behavior!

}

  直接而且类型安全,就像我们所喜欢的那样。

  但是它还不是异常安全。如果SpecialString生产了,但还没有调用for_each,一个异常被抛出,泄漏将出现。这个问题可以用很多方法解决,但最简单的也许是使用智能指针容器取代指针容器,通常使用一个引用记数的智能指针(如果不熟悉智能指针的概念,可以在中高级C++读物中找到。在More Effective C++中,这些材料在Item 28。)

  STL本身并不包括引用记数的智能指针,编写一个好的-所有情况下都正确-太富有技巧,因此除非真的需要,并不需要这样做。我(作者)1996年在More Effective C++发布了了一个引用记数的智能指针,尽管它基于一些确定的智能指针实现,而且在发布前由多位有经验的开发者讨论过,但是这些年还是有一堆准确的Bug被发现。很多引用记数的智能指针可能失败的微妙情况被说明。(细节在More Effective C++勘误中讨论)

  幸运地,几乎不需要自己写一个智能指针,因为已验正的实现并不难找。在Boost库(参考条款50)中就有一个这样的share_ptr。使用Boost的share_ptr,本条款最初的例子可以重写为:

void doSomething()

{

typedef boost::shared_ ptr<Widget> SPW; //SPW = "shared_ptr

// to Widget"

vector<SPW> vwp;

for (int i = 0; i < SOME_MAGIC_NUMBER; ++i)

vwp.push_back(SPW new Widget);   // create a SPW from a

// Widget*, then do a

//push_back on it

…                                  // use vwp

}   // no Widgets are leaked here, not

// even if an exception is thrown

//in the code above

  千万不能被auto_ptr愚弄了,不要认为创建auto_ptr的容器,指针会被自动删除。这是可怕是想法,它是如此危险,我准备用整个条款8来说明你不应使用它。

  应记住的是STL容器是智能的,但它不足以知道是否要删除它包含的指针。为了避免资源泄漏,使用指针容器时应删除指针。你需要使用智能指针或在容器销毁前手工删除每一个指针。

  最后,一个类似于DeleteObject的结构可以方便地避免使用指针容器时的资源泄漏,这也许会使你联想起,也许可能创建一个类似的DeleteArray,避免使用数组指针容器时的资源泄漏。当然,这是可能的,但是是否明智就是另一个问题了。条款13解释了为什么动态申请数组总是不如vector和string对象。所以在你坐下来写DeleteArray之前,请先看一看条款13。如果幸运,DeleteArray的时代将永远不会到来。