4

私はこれについて確信が持てず、少し検索しても特に役立つものは何も見つかりませんでした。したがって、いくつかのクラス C1 および C2 を含む名前空間を持つヘッダー ファイルがあるとします。

namespace my_namesp {

class C1 {
public:
  blah1;
  ...
private:
  blah2;
...
};

class C2 {
public:
  junk1;
  ...
private:
  junk2;
  ...
};

} //-End namespace

実装 (CPP) で、C1、C2 のすべてのメンバー関数が定義されていると仮定し、次に、C1 と C2 に共有させたい共通データ、たとえば列挙型と文字列配列があるとしますが、そうではありません。必ずしもどちらかのクラスの一部である必要はありません。次に、次のことを行うことは合法ですか (注: ビルドして正常に動作します)。この実装をクライアント アプリケーションのライブラリとしてエクスポートする場合はどうでしょうか。これはまだ機能しますか？何らかの理由で、この種のデザインは嫌われているのでしょうか? おそらく、OOP の特定の機能がこの種のことに適しているのではないでしょうか?

namespace my_namesp {

enum some_list_num {
   list_member1,
   list_member2,
   ...,
   list_length
}

static const std::string string_list[] = {
   str1,
   str2,
   ...,
   strN 
}

return_type C1::some_func1(...) {
   ...
}

...

return_type C1::some_func1(...) {
   ...
}

} //-End my namespace

アイデア/修正をお寄せいただきありがとうございます。

4

1 に答える 1

7

C1 と C2 が、翻訳単位に対してローカルに保持する必要がある実装の詳細を共有している場合、それは問題ありません。

それらを cpp ファイルの匿名名前空間に配置することをお勧めします。これにより、後でリンカー シンボルが衝突するリスクがなくなります (つまり、ライブラリ クライアントが名前空間に何かを急いで追加し、誤って「プライベート」名の 1 つを再利用した場合)。 .

cpp ファイルは次のようになります。

namespace { // private implementation details

    enum some_list_num {
       list_member1,
       list_member1,
       ...,
       list_length
    }

    static const std::string string_list[] = {
       str1,
       str2,
       ...,
       strN 
    }

}

namespace my_namesp { // define externally-visible functions etc.

    return_type C1::some_func1(...) {
       ...
    }

    return_type C1::some_func1(...) {
       ...
    }
}
于 2012-06-25T22:05:31.773 に答える