Effective STL 条款38

最新推荐文章于 2016-04-20 09:12:48 发布

AMin2001

最新推荐文章于 2016-04-20 09:12:48 发布

阅读量1.5k

点赞数

分类专栏： C++ 文章标签： c++ class each function 算法 functor

本文链接：https://blog.csdn.net/AMin2001/article/details/8069

版权

C++ 专栏收录该内容

32 篇文章 0 订阅

订阅专栏

条款38：把仿函数类设计为用于值传递

C和C++都不允许你真的把函数作为参数传递给其他函数。取而代之的是，你必须传指针给函数。比如，这里有一个标准库函数qsort的声明：

void qsort(void *base, size_t nmemb, size_t size, 
   int (*cmpfcn)(const void*, const void*));

条款46解释了为什么sort算法一般来说是比qsort函数更好的选择，但在这里那不是问题。问题是qsort声明的参数cmpfcn。一旦你忽略了所有的星号，就可以清楚地看出作为cmpfcn传递的参数，一个指向函数的指针，是从调用端拷贝（也就是，值传递）给qsort。这是C和C++标准库都遵循的一般准则，也就是，函数指针是值传递。

STL函数对象在函数指针之后成型，所以STL中的习惯是当传给函数和从函数返回时函数对象也是值传递的（也就是拷贝）。最好的证据是标准的for_each声明，这个算法通过值传递获取和返回函数对象：

template<class InputIterator,
  class Function>
Function     // 注意值返回
for_each(InputIterator first,
  InputIterator last,
  Function f);  // 注意值传递

实际上，值传递的情况并不是完全打不破的，因为for_each的调用者在调用点可以显式指定参数类型。比如，下面的代码可以使for_each通过引用传递和返回它的仿函数：

class DoSomething:
 public unary_function<int, void> {  // 条款40解释了这个基类
 void operator()(int x) {...}
 ...
};
typedef deque<int>::iterator DequeIntIter;  // 方便的typedef
deque<int> di;
...
DoSomething d;     // 建立一个函数对象
...
for_each<DequeIntIter,    // 调用for_each，参数
  DoSomething&>(di.begin(),  // 类型是DequeIntIter
  di.end(),    // 和DoSomething&；
  d);    // 这迫使d按引用
      // 传递和返回

但是STL的用户不能做这样的事，如果函数对象是引用传递，有些STL算法的实现甚至不能编译。在本条款的剩余部分，我会继续假设函数对象总是值传递。实际上，这事实上总是真的。

因为函数对象以值传递和返回，你的任务就是确保当那么传递（也就是拷贝）时你的函数对象行为良好。这暗示了两个东西。第一，你的函数对象应该很小。否则它们的拷贝会很昂贵。第二，你的函数对象必须单态（也就是，非多态）——它们不能用虚函数。那是因为派生类对象以值传递代入基类类型的参数会造成切割问题：在拷贝时，它们的派生部分被删除。（切割问题怎么影响你使用STL的另一个例子参见条款3。）

当然效率很重要，避免切割问题也是，但不是所有的仿函数都是小的、单态的。函数对象比真的函数优越的的原因之一是仿函数可以包含你需要的所有状态。有些函数对象自然会很重，保持传这样的仿函数给STL算法和传它们的函数版本一样容易是很重要的。

禁止多态仿函数是不切实际的。C++支持继承层次和动态绑定，这些特性在设计仿函数类和其他东西的时候一样有用。仿函数类如果缺少继承就像C++缺少“++”。的确有办法让大的和/或多态的函数对象仍然允许它们把以值传递仿函数的方式遍布STL。

这就是了。带着你要放进你的仿函数类的数据和/或多态，把它们移到另一个类中。然后给你的仿函数一个指向这个新类的指针。比如，如果你想要建立一个包含很多数据的多态仿函数类。

template<typename T>
class BPFC:     // BPFC = “Big Polymorphic
 public     // Functor Class”
  unary_function<T, void> {  // 条款40解释了这个基类
private:
 Widget w;     // 这个类有很多数据，
 Int x;     // 所以用值传递
 ...     // 会影响效率
public:
 virtual void operator()(const T& val) const; // 这是一个虚函数，
 ...     // 所以切割时会出问题
};

建立一个包含一个指向实现类的指针的小而单态的类，然后把所有数据和虚函数放到实现类：

template<typename T>     // 用于修改的BPFC
class BPFCImpl{      // 的新实现类
private:
 Widget w;      // 以前在BPFC里的所有数据
 int x;      // 现在在这里
 ...
 virtual ~BPFCImpl();    // 多态类需要
       // 虚析构函数
 virtual void operator()(const T& val) const;
 friend class BPFC<T>;    // 让BPFC可以访问这些数据
};
template<typename T>
class BPFC:      // 小的，单态版的BPFC
 public unary_function<T, void> {
private:
 BPFCImpl<T> *pImpl;    // 这是BPFC唯一的数据
public:
 void operator()(const T& val) const   // 现在非虚；
 {      // 调用BPFCImpl的
  pImpl->operator() (val);
 }
 ...
};

BPFC::operator()的实现例证了BPFC所有的虚函数是怎么实现的：它们调用了在BPFCImpl中它们真的虚函数。结果是仿函数类（BPFC）是小而单态的，但可以访问大量状态而且行为多态。

我在这里忽略了很多细节，因为我勾勒出的基本技术在C++圈子中已经广为人知了。《Effective C++》的条款34中有。在Gamma等的《设计模式》[6]中，这叫做“Bridge模式”。Sutter在他的《Exceptional C++》[8]中叫它“Pimpl惯用法”.

从STL的视角看来，要记住的最重要的东西是使用这种技术的仿函数类必须支持合理方式的拷贝。如果你是上面BPFC的作者，你就必须保证它的拷贝构造函数对指向的BPFCImpl对象做了合理的事情。也许最简单的合理的东西是引用计数，使用类似Boost的shared_ptr，你可以在条款50中了解它.

实际上，对于本条款的目的，唯一你必须担心的是BPFC的拷贝构造函数的行为，因为当在STL中被传递或从一个函数返回时，函数对象总是被拷贝——值传递，记得吗？那意味着两件事。让它们小，而且让它们单态。