19

ネストされた名前空間を使用すると、完全修飾名が非常に長くなることがあります。タイピングの量を減らすために使用できることはわかっていnamespace abc = aaa::bbb::cccます (場合によっては読みやすさも向上する可能性があります)。

ただし、プロジェクト内のすべてのファイルでこの名前変更を実現する最善の方法は何なのかはわかりません。単純なアプローチ (つまり、使用ごとに長い名前空間の名前を変更する) は、異なるファイルで同じ完全修飾名に異なる短い名前を使用することになる可能性があります。そのため、これを行うためのより一貫した方法を考え出すことを考えていました。

たとえば、次のようなものとします。

project
  |- client
  |   |- core
  |   |- plugin
  |   |- util
  |- server
      ...

削減された名前を含め、ディレクトリごとに 1 つのヘッダーを作成することを考えていました。たとえば、project/client/core/core.h含まれますnamespace pr_cl_core = project::client::core(この短い名前の例はかなり貧弱ですが、実際のプロジェクトではもっと理にかなっています)。次に、core.hすべてのヘッダー ファイルに をインクルードしてproject/client/core、そのディレクトリのヘッダーがたとえば にインクルードされたときに、project/client/plugin/plugin_foo.h名前空間の短いバージョンをすぐに利用できるようにします。

これはそうするための良いアプローチですか？他に良い方法はありますか？

SO の C++ 名前空間 (たとえば、1および2 ) に関するいくつかの質問を見つけましたが、プロジェクト全体の方法で名前空間の名前変更を解決する方法に関連するものはありません。

編集:さらに、このようなメカニズムを使用して、プロジェクト全体の長い名前空間 (Boost のものなど) の名前を体系的に変更できます。たとえば、私は通常、次のような名前空間の名前を変更します。

namespace ip = boost::asio::ip;
namespace ptime = boost::posix_time;

現在、これは翻訳単位ごとに行っていますが、プロジェクト全体に対してグローバルなアプローチを使用して行いたいと考えています。

4

1 に答える 1

1

長い名前空間名を繰り返し入力する必要がある場合は、名前空間階層に何か問題があると思います。

クラスでも同じことがあり、繰り返し入力しているとしますobj->sub()->subsub()->some_method()。これは、デメテルの法則に違反します。クラスの場合、(ラッパー関数を作成することによって) コードをリファクタリングして、階層内の下位のクラスが 1 レベル上のメソッドにアクセスするだけで済むようにします。

同じことを名前空間でも行う必要があります。呼び出す必要がある場合project::client::coreは、ラッパー関数/クラスを に記述clientして、必要なインターフェイスを に公開する必要がありますproject。これをあらゆる場所で行う必要がある場合は、名前空間構造をフラットにして、clientとcoreが同じレベルになるようにしてみませんか?

Boost がネストされた名前空間を使用するという事実は、部分的にしか当てはまりません。ネストされた名前空間のほとんどは、クライアントによって呼び出されるのが好きauxであり、呼び出されることが想定されていないためです。detailたとえば、Boost.MPL は、ネストされた名前空間をむやみに公開しないように注意しているライブラリの非常に良い例です。

于 2012-07-06T11:51:50.170 に答える