私はプロジェクトで shared_ptr と STL を多用していますが、これが長すぎてエラーが発生しやすい次のような型につながっていますshared_ptr< vector< shared_ptr<const Foo> > >(私は ObjC プログラマーを好んで使用しており、長い名前が標準ですが、それでもこれは多すぎます)。これを一貫して呼び出し、"Ptr" は shared_ptr を意味し、"List" は shared_ptr のベクトルを意味するという命名規則を文書化する方がはるかに明確になると思いますFooListPtr。
これは typedef するのは簡単ですが、ヘッダーで頭を悩ませています。定義する場所にはいくつかのオプションがあるようですFooListPtr:
- Foo.h はすべてのヘッダーを絡み合わせ、深刻なビルドの問題を引き起こすため、実行できません。
- FooFwd.h（「転送ヘッダー」）。これが効果的なC++iosfwd.h に基づいて提案されています。非常に一貫性がありますが、ヘッダーの数を 2 倍に維持するオーバーヘッドは、せいぜい煩わしいようです。
- Common.h (すべてを 1 つのファイルにまとめます)。これにより、無関係な型が多数絡み合って再利用性が失われます。これでは、1 つのオブジェクトを選択して別のプロジェクトに移動することはできません。これでは意味がありません。
- まだ typedef されていない場合に typedef する、ある種の派手な #define マジック。私は、プリプロセッサが嫌いです。初心者がコードを理解するのが難しくなると思うからです。でも、もしかしたら...
- typedef ではなく、ベクター サブクラスを使用します。これは危険なようです...
ここにベストプラクティスはありますか? 再利用性、可読性、一貫性が最も重要である場合、実際のコードではどのようになるのでしょうか?
他のユーザーがディスカッションのための追加オプションを追加したい場合に備えて、このコミュニティ ウィキにマークを付けました。
ベストアンサー1
私は、このメソッドを使用していると思われるプロジェクトでプログラミングを行っていますcommon.h。このメソッドはそのプロジェクトで非常にうまく機能します。
ForwardsDecl.hプリコンパイル済みヘッダーには というファイルがあり、すべての重要なクラスと必要な typedef を単純に前方宣言します。 この場合はunique_ptrの代わりに が使用されますshared_ptrが、使用方法は同様です。 次のようになります。
// Forward declarations
class ObjectA;
class ObjectB;
class ObjectC;
// List typedefs
typedef std::vector<std::unique_ptr<ObjectA>> ObjectAList;
typedef std::vector<std::unique_ptr<ObjectB>> ObjectBList;
typedef std::vector<std::unique_ptr<ObjectC>> ObjectCList;
このコードは、クラスが前方宣言されているだけであっても Visual C++ 2010 で受け入れられます (完全なクラス定義は必要ないため、各クラスのヘッダー ファイルをインクルードする必要はありません)。これが標準であり、他のコンパイラが完全なクラス定義を必要とするかどうかはわかりませんが、そうでないことは便利です。別のクラス (ObjectD) は、ObjectA.h をインクルードしなくても、メンバーとして ObjectAList を持つことができます。これは、ヘッダー ファイルの依存関係を減らすのに非常に役立ちます。
前方宣言は一度だけ記述すればよく、その後の変更はクラスのヘッダー ファイルの完全な宣言でのみ行う必要があるため、メンテナンスは特に問題になりません (これにより、依存関係が減るため、再コンパイルされるソース ファイルが少なくなります)。
最後に、これはプロジェクト間で共有できるようです（自分では試していません）。プロジェクトが実際にObjectAを宣言していなくても、前方宣言されているだけなので問題はありませんし、使用しなくてもコンパイラは気にしません。したがって、ファイルには、使用されているすべてのプロジェクトのクラス名を含めることができ、特定のプロジェクトで一部が欠落していても問題ありません。必要なのは、必要な完全な宣言ヘッダー（例ObjectA.h：）が任意のファイルに含まれていることだけです。ソース（.cpp）ファイル実際に使う彼ら。