問題タブ [template-meta-programming]

クラスのテンプレート パラメーターの型に基づいて代入演算子を提供するテンプレート整数ラッパー クラスを作成しています。

operator= はメンバー テンプレートではないため、boost::enable_if_c を使用した SFINAE は機能しません。そのような機能を提供するための作業オプションは何ですか?

テンプレートをT=std::vector<T2>引数のみに一致させます（T2任意のタイプです）。boost::enable_ifテンプレート引数で使用できます。Tタイプが？であるかどうかをテストするにはどうすればよいstd::vectorですか？

T::iteratorコンテナ以外のタイプが置換の失敗につながり、考慮されないように、テンプレートに含めることができます（SFINAE）。ただし、この方法では、を定義するすべてのコンテナT::iteratorが一致するだけでなく、一致しますstd::vector<T2>。

コンパイル時に型がstlコンテナであるかどうかを判断するテンプレートを作成したいと思います。  

私は次のコードを持っています：

しかし、私はstd::vector<T,Alloc>, deque<T,Alloc>, set<T,Alloc,Comp>などに必要な専門分野を作成する方法がわかりません...

Baseから派生した100のクラスがあるとしましょう。これらの派生クラスのそれぞれには、コンパイル時に既知の[0,100）間の一意の識別子があります。

IDを受け取り、そのIDを持つ派生クラスの新しく割り当てられたインスタンスを返す必要がある関数があります。

IDごとに巨大なスイッチケースを用意するのは明らかに良い解決策ではありません。私が思いつくことができる最良の解決策の例を以下に示しますが、vtableによって導入されるオーバーヘッドなしでこれを行う方法があるように感じます。

私はばかげていますか、それともそれほど多くのスペースを必要としない別のアプローチがありますか？

同様の質問: constexpr ではなく、特殊なテンプレート構造体で実装されるのはなぜですか? type_traits–しかし、別の答えがあります。

エイリアス テンプレートは特殊化できないため、現在、型特性を直接実装するために使用できないことを認識しています¹。ただし、これは委員会の意識的な決定であり、私が見る限り、これを禁止する技術的な理由はありません。

では、型特性をエイリアス テンプレートとして実装し、構文を簡素化する方が理にかなっているのではないでしょうか?

検討

対

もちろん、これによりBoost.TypeTraitsから移行する際にインターフェースの破壊的な変更が発生しますが、これは本当に大きな問題なのでしょうか?

結局のところ、型が異なる名前空間に存在するため、コードを変更する必要があり、多くの現代の C++ プログラマーは名前空間を開くことに消極的であるため、明示的に修飾されます (変更される場合)。

一方で、コードは大幅に簡素化されます。また、テンプレートのメタプログラミングがしばしば深くネストされ、複雑で複雑になることを考えると、より明確なインターフェイスが有益であることは明らかです。

何か不足していますか？そうでない場合は、単なる当て推量ではなく、委員会の決定の根拠に関する知識に基づいた (そして引用できる) 回答をいただければ幸いです。

¹しかし、間接的には非常にうまくいっています! 検討：

現在のタイプmeta::is_pointer<T>に対応する場所。std::is_pointer<T>

Boost.MPLタイプのシーケンス（リストまたはベクトル）の生成を自動化する次のコードについて考えてみます。

Boost.MPLのドキュメントによると、boost::mpl::listシーケンスには最大で要素を含めることができ、コンパイラの場合BOOST_MPL_LIMIT_LIST_SIZEも同様に最大で。私のシステムでは、両方のマクロが20と評価されます。boost::mpl::vectorBOOST_MPL_LIMIT_VECTOR_SIZE

MSVC ++2010およびBoost1.47.0は、実際、文書化された20要素を超えるベクトルを生成することはできません。ただし、最大247個の要素を含むリストを生成できるのは驚くべきことです。

なぜこれが起こるのか誰かが知っていますか？

https://stackoverflow.com/a/1967183/134841では、メンバーが存在するかどうか、場合によってはタイプのサブクラスに存在するかどうかを静的にチェックするためのソリューションが提供されています。

ただし、C ++ 11finalクラスでは機能しません。これは、テスト対象のクラスから継承するためfinalです。

OTOH、これ：

reserve(int/size_t)ベースクラスでメソッドが見つかりません。

reserved()のベースクラスで検出され、そうであるT場合でも機能するこのメタ関数の実装はありTますfinalか？

現在、次のものをコンパイルしようとしています。

ただし、特殊化は 2 つの可能なto_foo()メンバーの存在によって混乱するため、デフォルトのケースが選択されます。to_foo()メンバーの 1 つを削除するとすぐにcallX()機能しますが、constness と一致しないため、メソッドの 1 つが失敗します。

この場合、この機能を検出する方法はありますか?

編集：

以下は ideone の例です: http://ideone.com/E6saX

メソッドの 1 つを削除すると、問題なく動作します: http://ideone.com/iBKoN

「メンバーのチェック」では、おそらく基本クラスのC ++ 11バージョンで、C++でも機能する継承されたメンバー関数をチェックするためにSFINAEからC++11バージョンの従来のメンバーチェックタイプ特性を開発しました。 11finalクラスですが、C ++ 11機能（つまり、decltype）も使用します。

MSVCは、VS2005以降に名前がfinal付けられた非標準の拡張機能として使用されていますが、VS2010でのみ追加されています。そのため、VS2005と2008では、マークされたクラスが従来の型特性を破り、C++11バージョンを使用できなくなります。sealeddecltypesealed

それで、has_resize_methodVC2005 / 08sealedクラスでも機能するように定式化する方法はありますか？

明らかに、C++11のみの機能を使用してC++11のみの問題（）を回避するのと同じように、VSのみの拡張機能を使用してクラスfinalのVS2005/08のみの問題を回避しますがsealed3セットのコンパイラ{C++11、{VS2005、VS2008}、その他すべて}で機能するソリューションがあるとしたら、それはすばらしいことですが、多分多すぎて要求できません:)