-3

boost::operators に触発されて、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_;
};

これはコンパイルされないため、明らかに何かが間違っています。私の質問は、これを行うことができますか？

4

2 に答える 2

3

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_facadeBoost.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意図的なものです。

于 2013-06-12T10:59:00.603 に答える
0

私が理解できる最善のことは、あなたがニワトリ/タマゴの問題を抱えているということです.

構造体 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は現在ベースで使用されていません。別の計画のために残しました)

于 2013-06-12T10:45:13.080 に答える