C ++の内部typedefs-良いスタイルか悪いスタイルか？

私が最近頻繁に行っているのは、そのクラス内の特定のクラスに関連するtypedefを宣言することです。

class Lorem
{
    typedef boost::shared_ptr<Lorem> ptr;
    typedef std::vector<Lorem::ptr>  vector;

//
// ...
//
};

これらのタイプは、コードの他の場所で使用されます。

Lorem::vector lorems;
Lorem::ptr    lorem( new Lorem() );

lorems.push_back( lorem );

私が好きな理由：

• クラステンプレートによって導入されたノイズを減らし、にstd::vector<Lorem>なりますLorem::vector。
• これは意図の表明として機能します。上記の例では、Loremクラスは参照カウントboost::shared_ptrされ、ベクトルに格納されることを目的としています。
• これにより、実装の変更が可能になります。つまりboost::intrusive_ptr、後の段階でLoremを（を介して）侵入参照参照に変更する必要がある場合、コードへの影響は最小限になります。
• 私はそれは「きれい」に見え、間違いなく読みやすいと思います。

気に入らない理由：

• 依存関係に問題がある場合があります-たとえば、Lorem::vector別のクラス内にを埋め込みたいが、（ヘッダーファイルに依存関係を導入するのではなく）Loremを転送宣言するだけでよい（またはしたい）場合は、最終的に明示的な型（たとえば、boost::shared_ptr<Lorem>ではなくLorem::ptr）。これは少し矛盾します。
• それはあまり一般的ではないかもしれません、それゆえ理解するのは難しいですか？

私は自分のコーディングスタイルで客観的になるように努めていますので、私の考えを少し分析できるように、それについて他の意見を得ることは良いでしょう。

素晴らしいスタイルだと思いますし、自分で使っています。名前のスコープをできる限り制限することが常に最善であり、C ++でこれを行うにはクラスの使用が最善の方法です。たとえば、C ++標準ライブラリは、クラス内でtypedefを頻繁に使用します。

これは意図のステートメントとして機能します。上記の例では、Loremクラスはboost :: shared_ptrを介して参照カウントされ、ベクトルに格納されることを目的としています。

これはまさにそれが行わないことです。

コードに「Foo :: Ptr」が表示されている場合、それがshared_ptrかFoo *（STLにはT：の:: typetypesが含まれているのか、覚えている）かどうかはまったくわかりません。特に 共有ポインターの場合、typedefはまったく提供しませんが、コードでshared_ptrを明示的に使用し続けます。

実際、テンプレートメタプログラミング以外でtypedefを使用することはほとんどありません。

STLは常にこの種のことを行います

メンバー関数とネストされたtypedefの概念で定義された概念を持つSTL設計は、歴史的な袋小路であり、最新のテンプレートライブラリは組み込みの型を除外しないため、無料の関数と特性クラス（Boost.Graphを参照）を使用します。コンセプトをモデル化すること、および特定のテンプレートライブラリのコンセプトを念頭に置いて設計されていないタイプを容易に適合させることができるため。

同じ間違いをする理由としてSTLを使用しないでください。

Typedefは、C ++で構築されたポリシーベースの設計と特性です。そのため、C ++のジェネリックプログラミングの能力は、typedef自体に由来します。

typdefは間違いなく優れたスタイルです。そして、あなたの「私が好きな理由」はすべて良くて正しいです。

それに関してあなたが抱えている問題について。まあ、前方宣言は聖杯ではありません。マルチレベルの依存関係を回避するようにコードを設計するだけです。

typedefをクラスの外に移動することはできますが、Class :: ptrはClassPtrよりもはるかにきれいなので、私はこれを行いません。それは私にとって名前空間のようなものです-物事はスコープ内で接続されたままです。

たまにやった

Trait<Loren>::ptr
Trait<Loren>::collection
Trait<Loren>::map

そして、それはすべてのドメインクラスに対してデフォルトであり、特定のもののためにいくらか特殊化することができます。

STLは常にこのタイプのことを行います。typedefはSTLの多くのクラスのインターフェースの一部です。

reference
iterator
size_type
value_type
etc...

さまざまなSTLテンプレートクラスのインターフェイスの一部であるすべてのtypedefです。

これに対する別の投票は良い考えです。時間と空間の両方で効率的でなければならないシミュレーションを書くときに、私はこれを始めました。すべての値の型には、ブースト共有ポインターとして開始されたPtr typedefがありました。次に、いくつかのプロファイリングを行い、これらのオブジェクトが使用されているコードを変更せずに、ブースト侵入型ポインターに変更しました。

これが機能するのは、クラスが使用される場所がわかっている場合のみであり、すべての使用に同じ要件があることに注意してください。たとえば、ライブラリを記述するときに、それが使用されるコンテキストを知ることができないため、これをライブラリコードで使用しません。

現在私はコードに取り組んでおり、この種のtypedefを集中的に使用しています。これまでのところそれで結構です。

しかし、反復typedefがかなり頻繁にあり、定義がいくつかのクラスに分割されており、どの型を処理しているのか本当に分からないことに気づきました。私の仕事は、これらのtypedefの背後に隠されているいくつかの複雑なデータ構造のサイズを要約することです。そのため、既存のインターフェースに依存することはできません。3〜6レベルのネストされた名前空間と組み合わせると、混乱を招きます。

それらを使用する前に、考慮すべきいくつかのポイントがあります

• 他の誰かがこれらのtypedefを必要としますか？クラスは他のクラスでよく使用されていますか？
• 使用方法を短くするか、クラスを非表示にしますか？（非表示の場合は、インターフェースについても考えることができます。）
• 他の人がコードを扱っていますか？どうやってやっているの？彼らはそれが簡単だと思いますか、それとも混乱しますか？

これらのtypedefをクラスの外に移動することをお勧めします。このようにして、共有ポインターとベクトルクラスへの直接の依存関係を削除し、必要なときにのみそれらを含めることができます。クラスの実装でこれらの型を使用しているのでない限り、それらは内部のtypedefであってはならないと私は考えています。

これらはクラス内で宣言するのではなく、typedefを介した型エイリアスによって解決されるため、この理由は依然として一致しています。

typedefがクラス自体の中でのみ使用されている場合（つまり、プライベートとして宣言されている場合）、それは良い考えだと思います。しかし、あなたが与える理由のために、typedefがクラスの外で知られる必要があるなら、私はそれを使いません。その場合は、クラスの外に移動することをお勧めします。