如何使用“Barton-Nackman技巧”来实现trival方法?

时间:2013-06-12 10:20:10

标签: c++ templates

受到boost ::运算符的启发我认为Barton-Nackman习惯用法可以用来实现trival成员方法。

以下是我试过的(不编译)

template<typename T>
class impl_get_set {
    typename T::storage_type get() const {
        return static_cast<const T *>(this)->data_;
    }

    void set(typename T::storage_type d) {
        *static_cast<T *>(this)->data_ = d;
    }
};

struct A : public impl_get_set<A> {
    typedef int storage_type;
    storage_type data_;
};

struct B : public impl_get_set<B> {
    typedef double storage_type;
    storage_type data_;
};

由于这不能编译,显然我出错了。我的问题是,这可以做到,如果是这样的话?

2 个答案:

答案 0 :(得分:2)

使用CRTP时,在设计基础时必须小心,即在这种情况下impl_get_set。当派生类实例化基本特化时,例如,与A: public impl_get_set<A>一样,A类仍然不完整。

然而,impl_get_set的定义在成员函数声明中使用typename T::storage_type。此用途需要完整的T。 C ++ 03解决这个问题的方法是使CRTP基础可能需要的任何相关类型成为类模板参数的一部分:

template<typename Derived, typename StorageType>
struct get_set {
    typedef StorageType storage_type;

    // It's possible to define those inline as before where
    // Derived will be complete in the body -- which is why
    // CRTP is possible at all in the first place
    storage_type get() const;
    void set(storage_type s);

    // Convenience for clients:
protected:
    typedef get_set get_set_base;
};

struct A: get_set<A, int> {
    // Member type is inherited
    storage_type data;
};

template<typename T>
struct B: get_set<B<T>, double> {
    // Incorrect, storage_type is dependent
    // storage_type data;

    // First possibility, storage_type is
    // still inherited although dependent
    // typename B::storage_type data;

    // Second possibility, convenient if
    // storage_type is used multiple times
    using typename B::get_set_base::storage_type;
    storage_type data;
    void foo(storage_type s);
};

boost::iterator_facade是Boost.Iterator中编写良好的C ++ 03风格CRTP包装器的一个很好的例子。


C ++ 11提供了另一种编写CRTP基础的方法,这部分归功于函数模板的默认模板参数。通过使派生类参数再次依赖,我们可以像使用它一样使用它 - 只有在CRTP基本特化的成员函数模板实例化后才会被检查,一旦完成,而不是在CRTP基础专业化时本身就是:

// Identity metafunction that accepts any dummy additional
// parameters
template<typename T, typename... Dependent>
struct depend_on { using type = T; };

// DependOn<T, D> is the same as using T directly, except that
// it possibly is dependent on D
template<typename t, typename... D>
using DependOn = typename depend_on<T, D...>::type;

template<typename Derived>
struct get_set {
    template<
        // Dummy parameter to force dependent type
        typename D = void
        , typename Storage = typename DependOn<Derived, D>::storage_type
     >
     Storage get() const
     {
         // Nothing to change, Derived still complete here
     }
};

事实上,对于您的示例get_set,可以说不需要关心成员类型是否存在:

// std::declval is from <utility>

template<
    typename D = void
    , typename Self = DependOn<Derived, D>
>
auto get() const
-> decltype( std::declval<Self const&>().data )
{ return static_cast<Derived const&>(*this).data; }

get的这种实现与您自己的语义略有不同,因为它返回对data的引用,但这是故意的。

答案 1 :(得分:0)

我能想到的最好的就是你遇到了鸡/蛋问题。

struct A使用impl_get_set作为基础,强制实例化。但在那时A是不完整的,其内容尚不可用。因此T :: storage_type无法解析为任何内容。

我找到的唯一解决方法是为impl_get_set添加另一个模板参数并从上面传递它。所以走向相反的方向:

template<typename T, typename ST>
class impl_get_set {
public:  
    typedef ST storage_type;
    storage_type get() const {
        return static_cast<const T *>(this)->data_;
    }

    void set(storage_type d) {
        *static_cast<T *>(this)->data_ = d;
    }
};

struct A : public impl_get_set<A, int> {
    storage_type data_;
};

(A目前没有在基地使用,我把它留给了可能的其他计划)