私は簡単に、標準の識別子の前に.std::
を付ける代わりにusing namespace std;
. しかし、私は C# を使い始めて、必要な using ディレクティブを追加するのが非常に普通であることに気付きました。つまり、次のようになります。
using System;
Console.Write("foo");
それ以外の:
System.Console.Write("foo");
どうやら、このトピックに関する C# の質問からわかったように、その使用法は、C# の個々のシステム名前空間が C++ よりもはるかに小さいという事実に由来するstd
ため、名前の衝突に関連する問題が解消されます。可能性が低く (ライブラリが名前の衝突で更新された場合は、完全修飾名で検索して置き換えることができます)、名前空間が処理するのに十分小さいため、表示される Intellisense オプションのがらくたの負荷に関連する問題が解消されます。
問題は、これらが C# で using ディレクティブを使用する永続的な理由である場合、C++ にも同じことが当てはまるかということです。これを小さなサードパーティの名前空間や独自の小さな名前空間に適用することは一般的に受け入れられますか?
今、これが少し論争を引き起こすかもしれないことを理解しています。この瞬間を利用して、それが議論にならないようにお願いしたいと思います. 良い答えには、根拠、つまり長所または短所が含まれている必要があります。また、ある方法を別の方法で使用することによって実際に価値のある違いがどのように生じるかを示す必要があります。
私がこれを尋ねる理由は、問題を解決し、おそらく C++ でディレクティブを使用することは悪いことであるという考えを取り除くためです。確かに、必要に応じて名前空間エイリアスを使用してより長い名前空間名を削減でき、必要に応じて完全修飾名を使用することもできますが、using ディレクティブを使用すると、ユーザー定義のリテラル演算子などの一部のメンバーへのアクセスが大幅に容易になることがあります。つまり、using ディレクティブを使用するか、関数構文でオペレーター メソッドを呼び出す必要があり、そもそもオペレーターを使用する目的全体が無効になります。
たとえば、名前空間がありました (これには、キーボード キーを表す構造と、読み取り可能な代替アクセス手段としてのリテラル サフィックスが含まれます。
"caps lock"_key.disable();
ここでの問題は、以前にusing namespace Whatever;
orを挿入していない限りusing Whatever::operator"" _key;
、コードがコンパイルされないことです。これは、ユーザーにとって悪いニュースです。
ディレクティブを使用std
すると、そのヘッダーのユーザーに不要な余分なものをもたらすような方法で使用される場合、またはヘッダーで使用される場合に明らかな問題があります。ヘッダ?毎回各修飾子を入力する必要がないため、キーストロークを節約できます。また、今日の Intellisense 機能を使用すると、修飾されていない識別子がどの名前空間に属しているかをマウスオーバーするのと同じくらい簡単に見つけることができます。