分享

c++ Template CRTP

 quasiceo 2012-11-12

c++ Template CRTP


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.上,你可以找到该章节的免费版本。
       如果你抱着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 DerivedT>
class Base
{
  public:
     DerivedT& derived()
{
       return static_cast<DerivedT&>(*this);
}
     int foo()
{
     return this->derived().do_foo();
}
};
// User code
class Derived : public Base<Derived>
{
  public:
    int do_foo()
{
return 0;
}
};
       尽管do_foo是同一个实现,但是它可以被任意访问。为什么不将它设置为私有或者保护?答案是在foo函数中调用了Derived::do_foo,或者说,基类直接调用了一个在派生类中的函数。

       现在让我们找一个最简单方法,对于Derived的用户隐藏其实现细节。他应该足够简单,否则,用户将不会使用它。对于Base类的作者,这个稍微有些麻烦,但也应该是不难解决的。
       最显而易见的方法是在Base类和Derived类之间建立一个友谊关系。
// User code
class Derived : public Base<Derived>
{
  private:
    friend class Base<Derived>;
    int do_foo() { return 0; }
};

       这个解决方案并不是很完美,只因为一个简单的理由:每一个Base的模板参数类,都要定义一个friend声明。如果模板参数较多,那么这个声明列表将会很长。
       为了解决这个问题,同时将友元列表的长度固定,我们引入一个非模板类Accessor来做一次前向调用。
// Library code
class Accessor
{
  private:
    template<class> friend class Base;
    template<class DerivedT>
    static int foo(DerivedT& derived)
    {
        return derived.do_foo();
    }
};

       函数Base::foo应该称为Accessor::foo,他用来转发调用至Derived::do_foo。
       首先是这个调用链永远会成功,因为Base类是Accessor类的友元。
// Library code
template<class DerivedT>
class Base
{
  public:
    DerivedT& derived() {
       return static_cast<DerivedT&>(*this); }
    int foo()
{
        return Accessor::foo(this->derived());
}
};
       其次是当do_foo为公有或者当do_foo是保护同时Accessor类是Derived类的一个友元时才会成功。我们只感兴趣第二种情况。
// User code
class Derived : public Base<Derived>
{
  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> { };
       这里,将把最终类给模板参数列表。任何试图派生于Derived的类都没有太大意义,因为基类Base<Derived>仅仅知道Derived类,不能够定义生成Derived类的对象。
       由于我们不用考虑派生问题了,那么我们现在的目标就是如何实现在Base类中访问声明为protected的函数Derived::do_foo。
// User code
class Derived : public Base<Derived>
{
  protected:
    // No friend declaration here!
    int do_foo() { return 0; }
};
       通常,你可以在子类中访问基类中一个保护函数。现在的挑战是如何反过来访问。
       第一步是显而易见的。因为我们唯一的切入点是一个保护函数可以被Derived的后代访问。
struct BreakProtection : Derived
{
    static int foo(Derived& derived)
  {
      
  }
};
       当我们试图去完成他的实体:
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 DerivedT>
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<DerivedT&>(*this);
}
    int foo()
{
return accessor::foo( this->derived());
}
};
// User code
struct Derived : Base<Derived>
  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./articles/article.asp?p=31473
[Boost] Boost libraries. http://www..
[standard] ISO-IEC 14882:1998(E),Programming languages - C++.

      原文链接:http:///index.php/journals/296
译者评注:C++中的静多态和CRTP(奇异递归模板模式)已经不像5年前那样令人陌生。记得当时在国内论坛上讨论静多态的时候,很多人都是不约而同的反 应出?号。本人第一次接触这些也是在《C++ Template中文版》。还记得那个时候通宵达旦的看完《C++ Template中文版》之后,兴奋的想把所有类都用模板重构。然而做技术和做产品始终不同,做技术可以走在行业的前沿,不断的创新和改造,然而做产品则 需要中规中矩,基础稳定,便于维护的简单代码将永远放在首位。所以这几年来对于C++ 0X 的关注越来越少。有时看到一些同事写的代码,我总是特别强调代码的语义。极限编程中说过:“源代码就是注释”。其实这句话并不是强调你不用去写帮助文档, 就是强调代码的语义。举一个例子吧:一个类的析构函数到底是否为virutal,并不是取决你当时的心情。STL中的容器类的析构函数都不会定义 virtual,是因为没有这个关键字,就明确告诉你了这个类不希望被继承。这其实就是代码的语义。之所以翻译这篇文章,并不是想向大家讲述CRTP,而 是翻译了作者的态度。实现静多态很简单,但是实现好的CRTP却需要注意太多细节。本文从开始提出了一个想法,到最后通过技巧来写出了一个方法,直至最后 完善成几乎完美,这无处不体现着国外技术高手的对于技术一丝不苟的精神。想想为什么我们永远不可能写出来《Modern C++ Design》那样惊世骇俗的宝典?也许当自己有一天也习惯了利用随想设计,利用口语编程,同时对手下指指点点的时候,道理就会不言而喻了。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多