疯子阿虹的网络小家 - 疯子阿虹 - 网易博客
Better Encapsulation for the Curiously Recurring Template Pattern
使用CRTP做更好的封装
长久以来,C++一直突出于优秀的技巧和典范。老有名气的一个就是James Coplien在1995年提出的奇异递归模板模式(CRTP)。自那以后,CRTP便开始流行并在多个库中使用,尤其是Boost。例如,你可以在Boost.Iterator,Boost.Python或者Boost.Serialization库中看到他们。
在这篇文章中,我假设读者已经熟悉了CRTP。如果你想温习一下的话,我推荐你去阅读《C++模板编程》的第17章。在www.informit.com上,你可以找到该章节的免费版本。
如果你抱着OO的观点去看CRTP的话,你会发现,他和OO框架的有着共同的特点,都是基类调用虚函数,
真正的实现在派生类中。下面是一个最简单的OO框架实现代码:
// Library code
class Base
{
public:
virtual ~Base();
int foo() { return this->do_foo(); }
protected:
virtual int do_foo() = 0;
};
这里,Base::foo调用了一个虚函数do_foo,他是声明在Base类中的一个纯虚函数,而且他必须在基类中实现。也就是说,do_foo的实体出现在Derived类中。
// User code
class Derived : public Base
{
private:
virtual int do_foo() { return 0; }
};
这里有个有意思的地方是do_foo函数必须将访问符从保护修改成私有。这在C++中是比较好的访问控制,同时实现它只需要键入几个简单的字符。为什么要在这里有意强调do_foo不是共有使用呢?理由是一个用户应该尽力隐藏类的实现细节从而使类更加简单。(用户如果觉得这个类没有对外暴露的价值,甚至应该隐藏整个Derived类)。
现在让我们假设,有一些限制性的因素导致virtual函数不能胜任,同时框架的作者决定使用CRTP。
// Library code
template
class Base
{
public:
DerivedT& derived() {
return static_cast (*this); }
int foo() {
return this->derived().do_foo(); }
};
// User code
class Derived : public Base
{
public:
int do_foo() { return 0; }
};
尽管do_foo是同一个实现,但是它可以被任意访问。为什么不将它设置为私有或者保护?答案是在foo函数中调用了Derived::do_foo,或者说,基类直接调用了一个在派生类中的函数。
现在让我们找一个最简单方法,对于Derived的用户隐藏其实现细节。他应该足够简单,否则,用户将不会使用它。对于Base类的作者,这个稍微有些麻烦,但也应该是不难解决的。
最显而易见的方法是在Base类和Derived类之间建立一个友谊关系。
// User code
class Derived : public Base
{
private:
friend class Base ;
int do_foo() { return 0; }
};
这个解决方案并不是很完美,只因为一个简单的理由:每一个Base的模板参数类,都要定义一个friend声明。如果模板参数较多,那么这个声明列表将会很长。
为了解决这个问题,同时将友元列表的长度固定,我们引入一个非模板类Accessor来做一次前向调用。
// Library code
class Accessor
{
private:
template friend class Base;
template
static int foo(DerivedT& derived)
{
return derived.do_foo();
}
};
函数Base::foo应该称为Accessor::foo,他用来转发调用至Derived::do_foo。
首先是这个调用链永远会成功,因为Base类是Accessor类的友元。
// Library code
template
class Base
{
public:
DerivedT& derived() {
return static_cast (*this); }
int foo() {
return Accessor::foo(this->derived()); }
};
其次是当do_foo为公有或者当do_foo是保护同时Accessor类是Derived类的一个友元时才会成功。我们只感兴趣第二种情况。
// User code
class Derived : public Base
{
private:
friend class Accessor;
int do_foo() { return 0; }
};
这种方法被boost的多个库使用,譬如:Boost.Python中的def_visitor_access和Boost.Iterator的iterator_core_access都应该被声明为友元,以此来访问用户从def_visitor或者iterator_facade定义的私有函数。
尽管这个解决方案很简单。但是我们还是会有一种方法可以省略友元声明这个列表。在这种情况下,do_foo不能是私有,你必须要把它修改成保护。这其实没什么,因为这两者之间的访问控制差别对于CRTP的用户来说不重要。为什么呢?让我们看一下用户将如何派生于CRTP基类。
class Derived : public Base { /* ... */ };
这里,你将把最终类给模板参数列表。任何试图派生于Derived的类都没有太大意义,因为基类Base 仅仅知道Derived类。
由于我们不用考虑派生问题了,那么我们现在的目标就是如何实现在Base类中访问声明为protected的函数Derived::do_foo。
// User code
class Derived : public Base
{
protected:
// No friend declaration here!
int do_foo() { return 0; }
};
通常,你可以在子类中访问基类中一个保护函数。现在的挑战是如何反过来访问。
第一步是显而易见的。因为我们唯一的切入点是一个保护函数可以被Derived的后代访问。
struct BreakProtection : Derived
{
static int foo(Derived& derived) {
/* call do_foo here */ }
};
当我们试图去完成他的实体:
return derived.do_foo();
然而,BreakProtection::foo将会失败,因为根据C++标准,这个是被禁止的。
paragraph 11.5:
When a friend or a member function of a derived class references a protected nonstatic
member of a base class, an access check applies in addition to those described earlier
in clause 11. Except when forming a pointer to member (5.3.1), the access must be through
a pointer to, reference to, or object of the derived class itself
(or any class derived from that class) (5.2.5).
所以这个函数仅能被类型为BreakProtection的物体访问。
好吧,如果一个函数不能直接访问,那我们就间接访问。在BreakProtection类中得到do_foo的地址。
&BreakProtection::do_foo;
BreakProtection中并没有do_foo函数,因此,表达式将会被解析成&Derived:do_foo。
既然公有访问一个指向保护成员函数的指针是允许的,那我们就赶紧调用吧。
struct BreakProtection : Derived
{
static int foo(Derived& derived)
{
int (Derived::*fn)() = &BreakProtection::do_foo;
return (derived.*fn)();
}
};
为了更好的封装,BreakProtection可以被移动到Base模板类的私有节中。最终的解决方案是:
// Library code
template
class Base
{
private:
struct accessor : DerivedT
{
static int foo(DerivedT& derived)
{
int (DerivedT::*fn)() = &accessor::do_foo;
return (derived.*fn)();
}
};
public:
DerivedT& derived() {
return static_cast (*this); }
int foo() { return accessor::foo(
this->derived()); }
};
// User code
struct Derived : Base
protected:
int do_foo() { return 1; }
};
这回用户的代码比第一种解决方案苗条和清晰了,而库代码则没有太大的变动。
尽管如此,但还是有一个瑕疵的地方,大多数编译器不能优化间接的函数指针,即使他就是指向在原本对象的地方。
return (derived.*(&accessor::do_foo))();
无论如何,CRTP的也会比虚函数优化的更好。因为CRTP没有虚函数调用的负担,所以他的效率是很快的。
同时在编译的时候,代码类型是可以被编译器导出的,所以生成的代码也会更小。(当然,上面提到的第二种方法还是有了类型信息。我们希望未来的主流编译器都可以将其优化。)还有就是,使用成员函数指针不是很便利,尤其是重载函数。
参考文档
[Coplien] James O. Coplien. "Curiously Recurring Template Patterns", C++ Report, February 1995.
[Vandevoorde-] David Vandevoorde, Nicolai M. Josuttis. "C++ Templates: The Complete Guide". http://www.informit.com/articles/article.asp?p=31473
[Boost] Boost libraries. http://www.boost.org.
[standard] ISO-IEC 14882:1998(E),Programming languages - C++.