奇技淫巧C++之方法代理
author:非典型秃子
如果你有编写多线程程序的经历，遇到过需要共享对象的情况吗？比如，你想在两个线程中操作同一个容器，你会怎么做呢？是在每个地方都小心翼翼地加锁，还是封装一个来用？两种方法我都用过，但我比较青睐封装一个的办法，例如，封装一个带锁的队列，用于线程间的通信．
让我们先看看直接操作锁和对象的代码：
//declare:
std::Container cont;
LockType contLock;
...
//using:
contLock.lock();
cont.XXX();
contLock.unlock();
嗯，using下面的加锁和解锁的方法太老土，而且最关键的，还不安全，让我们稍加改善：
ScopedLock guard(contLock); //在ScopedLock的构造函数中lock，在析构函数中unlock
cont.XXX();
看上去稍好了一点，然而有两个小的缺点。前面提到共享对象，第一个缺点就是我们需要共享两个对象，容器和锁，这使得管理和传递共享对象都变得麻烦起来。另 一个缺点是，加锁的动作需要小心谨慎，千万别忘了。可惜，即使忘了，我们也不会从编译器这里得到任何帮助。这两个不便，都会促使我们考虑是不是把对象和锁 封装起来更好？很多时候，我们确实是这么做的，看一个deque的例子（省略std）.
template<typename T, typename Alloc= allocator<T> >
class shared_deque{
dequeT, Alloc> m_cont;
LockType m_lock;
...
void push_back(const_reference val){
ScopedLock guard(m_lock);
m_cont.push_back(val);
}
....
};
呼，终于好了，我们现在有了一个好用的shared_queue了。只是，类似那个push_back的东西，重复了几十遍，很无聊的，还有必要对 list也来一遍吗？算了吧！万幸，没有用basic_string，那家伙可有１００多个成员函数。有没有办法简化一下工作呢？重复的东西总是应该交给 计算机来做是不是？还好，C++正好能帮助我们实现这一目标，这个手法在MCD中被寥寥数语带过，就是那神奇的operator->()．
让我们回顾一下operator->的用法：用于对象指针，提取对象成员，函数或对象．许多smart pointer地实现都重载了这个运算符，从而可以模拟指针的语法．一般的重载形式是这样的：
cv1 T* operator->() cv2
这里返回的是T*类型，如果返回的不是指针类型呢？C++标准对此有特别规定，会继续调用返回值的operator->()方法，直到最终解析出一个指针类型．假定有下面的operator->展开过程：
object a-->b-->T pointer
(请 注意一下a,b,T对象的生命期，确定我们是安全地在使用这些对象．)a对象的operator->返回临时对象b,b对象的operator ->返回最终类型T*.那么，b对象必须在其T* operator->()调用之前创建好，而在T::XXX()方法调用之后被销毁，因为b是临时对象．嗯，好了，有点方向了：在b的构造函数中加 锁，在析构中解锁，就可以在调用T::XXX()方法时自动实现加锁可解锁了．
拓展一下思维，我们必须局限于锁和容器吗？不必．这个手法的本质效果是什么？就是在调用一个方法之前，插入一些操作，调用之后再插入一些操作（稍显遗憾的是，我们无法知道被调用的到底是什么方法）．但是，这也够我们做许多事情了．实现如下：
#include
template
<
typename Pointer,
typename Monitor,
typename ScopedType = typename Monitor::scope_type
>
class call_proxy
{
public:
typedef call_proxy self_type;
typedef Pointer pointer_type;
typedef Monitor monitor_type;
typedef ScopedType scoped_type;
typedef typename boost::call_traits<pointer_type>::param_type param_type;
typedef monitor_type& monitor_reference;
private:
struct proxy{
proxy(self_type* host) : m_host(host), m_s(host->m_monitor){};
pointer_type operator->(){
return m_host->m_obj;
}
private:
self_type* m_host;
scoped_type m_s;
proxy(const proxy&);
proxy& operator=(const proxy&)
};
friend struct proxy;
public:
call_proxy(param_type p, monitor_reference m) : m_obj(p), m_monitor(m){ assert(p);}
proxy operator->() {
return this;
}
private:
pointer_type m_obj;
boost::reference_wrapper<monitor_type> m_monitor;
};
为了可以和smart_pointer合作，call_proxy需要的第一个模版参数是被代理对象的指针类型，而不是自己产生指针类型，这就允许是一个 smart_pointer的类型．monitor类型本质上需要开始和结束两个方法，把它封装进ScopedType,依靠ScopedType的构造 和析构来完成．这样做的目的是避免对限制monitor的方法名称，可以看作是traits手法的简化版本．你可以自定义合适的ScopedType类 型．嵌套类proxy的构造函数的隐式转换是必要的，它可以消除额外的copy ctor的需求．
上述的实现代码已经没什么神奇之处可言了．使用方法如下：
typedef vector<int> MyVector;
MyVector cont;
LockType lock;
typedef call_proxy<MyVector*, LockType, LockType::scoped_lock> proxy_type;
proxy_type cont_proxy(&cont, lock);
至此，cont_proxy可以作为一个封装好的对象使用了．嗯，当然，cont_proxy的生命周期应该比cont来得短，这个问题就让程序员去保证吧．
剩下的问题：
call_proxy还有一些问题需要解决．我们在调用某些成员方法的时候，未必都要加锁．如果对象和锁是分离的，那么自然很容易处理．如果是手工封 装，虽然工程浩大，但是也可以在适当的地方加以特别处理．特别的，对于分离的对象和锁，我们还可以使用大粒度的锁定过程，从而改善某些性能．而这里的 call_proxy则没有这种灵活性，当然手工封装的类也无此灵活性．然而，我们还是可以改善call_proxy，从而在一定程度上获得这种灵活性的 好处，为call_proxy增加两个友元方法：
friend pointer_type getImp(const self_type& cp){ return cp.m_obj;}
friend monitor_reference getMonitor(const self_type& cp){ return cp.m_monitor;}
当我们需要大粒度的机制时可以这样：
{
proxy_type::scoped_type guard(getMonitor(cont_proxy));
getImp(cont_proxy)->XXX1();
getImp(cont_proxy)->XXX2();
...
}
对于新手，可能会奇怪getImp的用途，或者忘记调用，这不够优雅．但是这样的解决方案已经比较简单了，它简化了大部分的情况，而且留了一条优化的后路．
ps:
这种技巧性的东西不是软件开发的根本，不过是自己手痒而已，愿看到此文的程序员一笑而过．
发表于 @ 2007年03月28日 12:22:00|评论(loading...)|编辑