如何使用"Barton–Nackman trick"实现三元方法？

How do I use the "Barton–Nackman trick" to implement trival methods?

本文关键字：方法 三元 实现 Barton 何使用 Nackman trick      更新时间：2023-10-16

受boost::操作符的启发，我认为Barton-Nackman习惯用法可以用来实现来自平凡成员的方法。

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

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_;
};

由于这没有编译，显然是我错了。我的问题是，这能做到吗?如果能做到，怎么做?

当使用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的引用，但这是故意的。

我能想到的最好的办法就是你处在一个先有鸡还是先有蛋的问题中。

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目前没有在基地中使用，我把它留在了其他可能的计划中)

相关文章：