問題タブ [unnamed-namespace]

名前のない名前空間を使用する場合、別の名前空間内にネストされていると問題が発生しますか？たとえば、次のコードでFoo1.cppとFoo2.cppの間に実際の違いはありますか。

C ++で名前空間を使用して関数を定義し、それらが定義されているコンパイルユニットの外部から呼び出せないようにすることは、シンボルテーブルが大きくなるため、非常に大規模なコード環境では適切ではないと主張していると聞きました。名前のない場合にC++コンパイラが提供する自動生成された名前空間にこれらのシンボルへのエントリを含めることにより、不必要に大きくなります。

これはおそらく、上記が次のことを行うのと同じであると想定されていることを前提としています。

しかし、それは本当に簡単ですか？コンパイラは、生成された名前空間名のシンボルのシンボルテーブルエントリを作成する必要がありますか？

代わりに、そのような状況では、静的宣言を使用することが提案されていると聞きました。

名前のない名前空間に配置する代わりに関数の前に静的宣言を使用すると、関数が定義されているコンパイル単位の外部で関数にアクセスできなくなるのと同じ効果がありますか？シンボルテーブルを大きくしない可能性があることを除いて、これら2つのアプローチの間に違いはありますか？

名前のない名前空間によるシンボルテーブルの肥大化の問題は、C ++の一部の実装のバグにすぎないのでしょうか、それとも、コンパイラがそのような関数のエントリを作成するために標準で何らかの形で必要とされているのでしょうか。この膨張がバグと見なされる場合、これが問題にならない既知のコンパイラはありますか？

このコードをビルドしようとすると:

エラーが発生します：

を参照するために をput<int>使用していることは明らかです。匿名名前空間で参照するにはどうすればよいですか?putbar::putput<T>

名前のない名前空間とグローバル宣言の使用の違いは何ですか?
これら2つを使用するための特定のコンテキストはありますか?
外部ソース ファイル内の無名の名前空間コンポーネントにアクセスできますか?

Google C++ スタイル ガイドの名前空間セクションには、「ヘッダー ファイルで名前のない名前空間を使用すると、C++ One Definition Rule (ODR) に違反する可能性があります」と記載されています。

実装ファイルで名前のない名前空間を使用しないと ODR 違反が発生する理由は理解できますが、ヘッダーで使用するとどのように発生するかはわかりません。これがどのように違反を引き起こす可能性がありますか?

次のコードを検討してください。

このコードは無効です。の再定義がa行われているためです。しかし、私はこれが有効であることを期待していました。実際、秒。3.3.6/1 は次のように述べています。

[...] original-namespace-name によって示される潜在的なスコープは、そのoriginal-namespace-nameを持つ同じ宣言領域内の名前空間定義のそれぞれによって確立された宣言領域の連結です 。[...]

しかし、名前のない名前空間の定義は、original-namespace-definition ではなく、sec. 7.3.1/1 は次のように述べています。

と

さらに、秒。7.3.1.1 は次のように述べています。

unnamed-namespace-definition は、

inline は、unnamed-namespace-definition に出現する場合にのみ出現し、翻訳単位内のすべての一意の出現は同じ識別子に置き換えられ、この識別子はプログラム全体の他のすべての識別子とは異なります。

これは、名前のない 2 つの名前空間が異なるuniqueを持っていることを意味します。

私が引用したコードの動作を説明できますか?

私は新しい機能の既存のクラスを拡張していますが、どの設計ソリューションを使用するかについて疑問があります。いくつかあり、それぞれに長所と短所があります。私の場合は次のとおりです。特別な形式のファイル ヘッダーがあり、それを読み取って保存します。FileHeader という名前のクラスがあり、ストリームとの間のシリアル化とその他の機能を既に実装しています。私のタスク リストの項目の 1 つは、特定のタイム スタンプ機能を追加することです。タイムスタンプは、1994 年 1 月 1 日 00:00:00 からの秒数として読み取り/保存する必要があります。ただし、FileHeader クラスは日付と時刻を 2 つの個別の変数に格納します。したがって、秒から日付と時刻への変換を記述する必要があります。問題は、この機能をどこに配置するかです。secondsPerDay (60*60*24) と dateOrigin (1/1/1994) を定数として使用しています。

次のオプションがあることがわかりました。

A) FileHeader クラスのプライベート メソッドとして変換を実装します。secondsPerDay と dateOrigin は、クラスの静的プライベート定数になります。

これはかなり簡単です。しかし、私が気に入らないのは、すでに非常に重いクラスに責任が追加されることです。あなたはルールを知っています: 1 つのクラス = 1 つの責任。たとえば、メンテナンスは難しいでしょう。誰かが秒を分などに変更することを決定した場合、彼はメソッドを書き直しますが、十分に注意しないと、静的定数 secondsPerDay が残ってしまう可能性がありますが、それはもう必要ありません。さらに、実装の詳細にのみ影響するにもかかわらず、ヘッダー ファイルを更新したに違いないという事実も気に入りません。

B) .cpp ファイルの名前のない名前空間でのみ実装を行い、通常の関数と静的変数を使用します。

これらの関数を呼び出す FileHeader の save メソッドと restore メソッド。まあ、私はそれが好きです。私はヘッダーを台無しにしませんでした。クラスの FileHeader の責任は大きくなりませんでした。しかし、誰かが秒の代わりに分を使用するようにアルゴリズムを変更することを決定した場合、関数を変更できますが、注意を怠ると、不要になったにもかかわらず、不要な secondsPerDay 静的変数を残してしまいます。

C) FileHeader.cpp で名前のない名前空間を使用し、専用のクラスを使用します。

FileHeader の保存と復元は、これらの静的メソッドを呼び出します。

個人的には、このソリューションを選択しました。ヘッダーを台無しにせず、静的変数のスコープを視覚的に制限するため、誰かが TimeConverter の実装を秒単位から分単位に変更した場合、不要な静的変数 secondsPerDay を残さない可能性が非常に高くなります...現在、 TimeConverter は他のクラス (FileHeader のみ) では使用されませんが、これを変更すると、独自のヘッダーとソース ファイルに簡単に移動できます。

コードを書いているとき、これが新しい実装の詳細の既存のクラスの機能を拡張する私の通常の方法であることに気付きました。私はかなりの頻度でそれを行っているので、他の人が何を使用しているのか、またその理由について興味があります。私の経験によると、95% の開発者がオプション A を使用してクラスを拡張しています。だからここに質問があります：

• 他に良い便利なオプションはありますか？

• これらのオプションを使用することの重要な側面や意味を見逃していませんか?

更新：以下の回答の1つからのアドバイスに従って、オプションDも提示します：

そして、それに続く質問 - D は C よりも優れている点と、その逆の点はどうなのか。長所と短所は何ですか？

名前のない名前空間を使用して、関数と変数に内部リンケージを持たせることを理解しています。名前のない名前空間はヘッダー ファイルでは使用されません。ソースファイルのみ。ソースファイルで宣言された型は、外部では使用できません。では、名前のない名前空間に型を配置することの用途は何ですか?

名前のない名前空間に型を配置できることが言及されているこれらのリンクを参照してください。

• 静的よりも名前のない名前空間の優位性?
• 名前のない/匿名の名前空間と静的関数
• 名前のない名前空間が静的の「優れた」代替手段であるのはなぜですか?