本文探讨了C++中协变返回类型的概念及其在智能指针应用中的挑战。通过实例说明了如何在继承体系中利用boost::shared_ptr，并提出了一种解决方案来克服因智能指针类型不协变带来的问题。
covariant return type and boost::shared_ptr
covariant return type翻译为协变返回值,意义就是在虚函数的返回值上,可以使用子类对象,而不必是基类对象.下面是一个例子:
struct Object
{
public:
virtual ~Object()
{}
};
struct Cloneable: public Object
{
public:
virtual ~Cloneable()
{}
virtual Object* Clone() const = 0;
};
struct Foo : public Cloneable
{
virtual Foo* Clone() const //注意这里
{
return new Foo();
}
};
我们看到Foo的Clone函数返回的是Foo对象,而不是Object对象.显然,C++的这个特点,对于设计继承类层次来说,在某些情况下使用非常方便,因为你不必被强迫使用dynamic_cast或者static_cast来进行类型转换了.
boost::shared_ptr是boost智能指针中最为常用的一个,它是内存资源或者其他资源的正确释放的有力工具. boost::shared_ptr使用在函数返回值当中,也有很好的作用.例如上面的Clone函数的返回值是一个指针,那么这个指针的生命周期的维护就是一个问题.一般来说,这需要使用者和实现者之间有一个很好的协议,这个协议的严格遵守才能保证避免资源的泄露,这个问题也是C++世界中一个非常棘手的问题.引进boost::shared_ptr,可以在很大的程度上解决这个问题,代码如下:
struct Object
{
public:
virtual ~Object()
{}
};
typedef boost::shared_ptr<Object> ObjectPtr;
struct Cloneable: public Object
{
public:
virtual ~Cloneable()
{}
virtual ObjectPtr Clone() const = 0;
};
struct Foo;
typedef boost::shared_ptr<Foo> FooPtr;
struct Foo : public Cloneable
{
virtual FooPtr Clone() const
{
return boost::shared_ptr<Foo>(new Foo());
}
};
资源的释放由智能指针本身维护,用户不必再担心资源的泄露问题.这是一个非常好的方案.
但是,C++的世界不是如此的完美,上面的代码是不能编译成功的,原因是:虽然Object和Foo之间存在继承关系,但是ObjectPtr和FooPtr之间不存在继承关系,这意味着协变返回值在这里不起作用.
为了解决这个问题,在boost的新闻组上http://lists.boost.org/boost-users/2003/02/2996.php 给出了如下的方案(注意这里是针对我们的例子修改以后的):
struct Object
{
public:
virtual ~Object()
{}
};
typedef boost::shared_ptr<Object> ObjectPtr;
struct Cloneable: public Object
{
public:
virtual ~Cloneable()
{}
virtual ObjectPtr DoClone() const = 0;
};
struct Foo;
typedef boost::shared_ptr<Foo> FooPtr;
struct Foo : public Cloneable
{
virtual ObjectPtr DoClone() const
{
return boost::shared_ptr<Foo>(new Foo());
}
FooPtr Clone() const
{
return boost::dynamic_pointer_cast<X>(this-> DoClone ());
}
};
这个方案在一定程度上解决了问题,但是我个人非常不认同这个方案,主要的理由如下:
1. Cloneable类型是一个接口类,一般来说,接口的抽象程度比较高,使用范围也很广.接口一般是用来抽象概念的,上面改变接口函数的做法,在一定的程度上伤害了这个概念.试想,如果你是Cloneable的最初设计者,你会把接口声明为DoClone吗?这种技术妨碍概念设计的做法,是应该竭力避免的.
2. 即便是从纯粹技术的角度说,这种做法也存在问题.上面的例子是两层继承设计,当然在实际中也可能是三层或者更多的层次,我们就以三层为例,为了使用这种技术,还得设定一个新的名称,难道是DoDoClone?!显然,这个的技术会随着层次的加深而越发的不可接受.所以说,这个技术的扩展性比较差.
其实,我认为更好的方法在boost中已经使用,这个方法是:
1) 上层的接口设计保持不变,仍然是从概念出发,例如Cloneable的接口函数名称仍然是Clone,返回值类型是ObjectPtr;
2) 下层的接口直接继承上层的接口,如果是实现类,那么并不使用协变返回值的技术,仍然是返回ObjectPtr;
3) 提供一个模板化的全局函数,实现向上转型.
上面例子的做法是:
struct Object
{
public:
virtual ~Object()
{}
};
typedef boost::shared_ptr<Object> ObjectPtr;
struct Cloneable: public Object
{
public:
virtual ~Cloneable()
{}
virtual ObjectPtr Clone() const = 0;
};
struct Foo;
typedef boost::shared_ptr<Foo> FooPtr;
struct Foo : public Cloneable
{
virtual ObjectPtr Clone() const
{
return ObjectPtr <Foo>(new Foo());
}
};
template<class X> shared_ptr<X> clone(X const & x)
{
shared_ptr<X> px = boost::dynamic_pointer_cast<X>(x.Clone());
assert(px);
return px;
}
其实这里也可以使用boost:: static_pointer_cast.
扫一扫
7500
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
