私は文脈についてもっと知ることなく、2つの可能な答えを見ています。
template<typename T> class C;
template<template<typename> typename TT, typename T> class C<TT<T>> {
... static_assert(std::is_same<TT<T>, Accepted<T>>::value, "The given type is not an instantiation of Accepted!"); ...
}
これは非常に有用です - これは何のために特別ですか? 2番目のテンプレートがあるとします。 SortedAccepted<T>
という同じ要件を満たしていますが、テンプレート引数をAccepted<T>
に制限しています。
1つのオプションは、自分自身を受け入れたとして、それからの派生は同じ制約条件を満たさなければならないように契約として受け入れ設計することです:
template<template<typename> typename TT, typename T> class C {
... static_assert(std::is_base_of<Accepted<T>, TT<T>>::value,
"The given type is not a derivation of Accepted!"); ...
};
これが受け入れを延長する必要があることを設計原理から、次のではなく、その派生によって、修正された。前の例から、Acceptedは冪等のソートメソッド(accepted.sort().sort() == accepted.sort()
)を必要とするかもしれませんが、SortedAcceptedは暗黙的にこのプロパティを保持しますが、さらにsorted_accepted.sort() == sorted_accepted
を提供します。 Acceptedが期待される場所であればどこでもSortedAcceptedを許可することで失うものはありませんが、十分に得ることができます!
私があなたの問題を正しく理解していれば、あなたは形質とコンセプトに興味があるかもしれません。
<type_traits>
およびBoost's extensionsに見られるタイプの形質は、形質を共有するコレクション、これらの表現などについてコンパイル時の保証を提供します。たとえば、S s; T t; auto u = s + t
の場合、std::is_arithmetic<S>::value
およびstd::is_arithmetic<T>::value
がtrueの場合、std::is_arithmetic<decltype(u)>::value
がtrueになります。 is_floating_point
のいずれかである場合、uも同様です。
Conceptsは、型形質由来の次の論理的ステップである:本質的にはreified要件の形質である。 ( 'Concepts Lite')
「C」のようなものはどうですか? –
StoryTeller
@StoryTellerはコンパイルしないでください。追加するように編集しました。 – Danra
部分的な解決策としては、 'テンプレートクラスC;'として宣言し、 'テンプレート<テンプレート型名TT、型名T>構造体C > {...}'と定義し、TTが受け入れられる静的アサーション、それはあなたが満足している契約のみを表明することでリラックスすることができます。私は、一般的には、Acceptedを設計して内部的にその契約が満たされていることを要求/宣言し、与えられたタイプのAcceptedのインスタンス化が適切に行われていると主張する以上の型にCを無視します。 –