std;という記述をすることがあります。これによって、std::coutという記述をcoutというstd::を省略した形で簡潔に記述できるようになります。stdの利用は、サンプルプログラムでの活用や、その場限りの簡単なプログラムを書く分にはそれほど問題にはなりませんが、大規模なコードや継続的な保守・拡張を前提としたコードを書く際には、面倒な問題や複雑な挙動に直面する危険性があるため、できる限り使わないようにすることをオススメします。usingディレクティブの多用は、名前空間の汚染や機能名の競合が発生する問題、標準型とユーザ定義型の区別が曖昧になる問題など、様々な問題を引き起こすことにも繋がるため、仮に利用する場合には注意して慎重に扱う必要があります。問題が起こらないことが明確なケースでのみ利用するのがよいでしょう。名前空間;記法については以下の記事が参考になります。変数名と被るstd::を省略した記述を前提にコード書いてしまうと、ライブラリ側のシンボル名と自身が宣言した変数名が被ってしまう恐れがあります。begin(string);近年では略称を用いない命名が好まれる傾向にあるため、本来であれば、count変数やbegin変数のような明確な名称をそのまま使いたい所です。そのためusingディレクティブの利用によって生じる変数名と機能名の名前衝突のリスクは好ましくないものと言えます。usingディレクティブの乱用は、変数名の命名の幅を狭めることにも繋がります。ちなみに変数宣言時の型名と変数名については名前衝突が発生しません。コンストラクタ呼び出しは行えなくなります。クラスのコンストラクタ呼び出しにはならないこの場合、変数名stringをstrやtext等に書き直して型名と区別すると良いでしょう。《末尾空白あり》で文字列検索すれば、変数名のみが抽出される)。usingディレクティブを用いなければこのような区別は不要となります。ユーザ定義型との名前衝突が起こるユーザ定義された型名やシンボル名がstd側のメンバ名と重複してしまう場合もあります。ambiguousとりわけstdの場合は、インクルードされるヘッダファイルが増えれば増えるほど、名前空間の汚染が拡大し、名前衝突のリスクもより高まりやすくなるという問題があります。加えて、今後標準ライブラリに新しい関数やクラスが追加された場合のリスクにも注意しなければならなくなります。ユーザ定義型はキャメルケースで統一する等)などが考えられます。std;の利用自体を取りやめるという決断を迫られる場合もあります。その場合、既存のコードを大幅に修正する必要が生まれます(既存のstringをstd::stringに書き直したりする。必要なもののみを個別にusing宣言するようにする)。std;を使わないようにすることです。ユーザ定義型との区別が曖昧になる自身が定義した同名型との区別が曖昧になるというややこしい問題もあります。std::stringではない(ややこしい)}この曖昧さは、勘違いやミスの原因にもなりやすく危険です。標準ライブラリ側とユーザ定義側のどちらの機能が使われているのかの区別が付きにくくなるという問題もあります。これによってコード解読時やコードレビュー時に余計な精査コストを生んでしまう恐れがあります。どちらなのか区別が付かないf(move(obj));このようなケースでは、きちんと名前空間を明示してstd::moveと書くようにすると良いです。std::が明示されている完全修飾名の方が標準ライブラリ側の関数で、明示されていないほうが自作関数であるという区別が可能になります。多重定義された関数が呼ばれなくなる場合があるオーバーロード解決のケースによっては、読み手の意図に反する挙動を取ることがあります。これは思わぬ勘違いやバグにつながる危険性があるため注意が必要です。STD::f(T&&)}以上のことから、グローバル空間や特定の名前空間内におけるusingディレクティブの利用/採用は慎重に行う必要があります。小規模な開発シーンではそれほど問題にはならないですが、大規模なプロジェクトや複数のライブラリを併用する場面では可能な限り利用しないようにすることをオススメします。ユーザ定義型との区別が曖昧になる」の問題や、以下の特性を理解した上で使うようにしましょう。スコープ別の挙動に注意する名前空間内での利用と、グローバルスコープ/ファイルスコープでの利用で若干挙動の変化が発生するため注意してください。名前空間内でユーザ定義を行った場合には、グローバルスコープ時/ファイルスコープ時のようなエラーは発生しませんが、名前解決の方法が変わります。コードをリファクタリングしたり、移植したりする際にはこれらの違いや特性に十分注意して慎重に行う必要があります。}}複数の名前空間を取り込む際のリスク異なる名前空間同士に存在する同名のメンバが同一スコープ内に展開された際に、クラス名の名前衝突が発生してしまう問題もあります。ambiguousこの名前衝突の問題については、最初の内は問題になっていなくても、いずれ双方のライブラリ側で新しい機能名が追加されて、名前衝突に繋がてしまうケースが想定されます。std::string)。場合によっては「std以外の空間についてはusingディレクティブ用いないようにする」等の取り決めが必要になります。機能名の競合が発生した場合は、名前空間を明示する必要があります。スコープ解決演算子(::)を用いることで、グローバルスコープ側の機能名と名前空間内の機能名を区別することができます。名前空間`std`側の`string`クラス他にも、using宣言を行う方法があります。using宣言による再宣言により名前探索時の優先順位が明確化するため、名前競合を回避することに繋がります。string`型}特定の名前空間内でusing宣言を行えば、一括で名前解決を行うことができます。クラススコープでusing宣言が行えない問題の対応策としても有効です。個別にusingする以下のように必要な物のみを宣言すれば、名前空間を無駄に多く汚さずに済みます。std::vector<T>;使い方やより詳しい説明は以下のページで解説していますので参考にしてください。stdするどうしてもstd内のメンバを一括で利用できるようにしたいような場合は、関数内や名前空間内などの個別のローカル空間で利用すると比較的安全です。関数内で利用する関数内のローカルスコープで利用すれば、関数内でのみ全てのライブラリ関数やクラスを活用することが可能になります。その他の関数やスコープに名前が汚染することもありません。endl;}ブロックスコープで利用するif文やfor文、ブロック文等のブロックスコープ内で利用することも可能です。string("c");}特定のタイミングで利用するusingディレクティブは任意の行に記述することができます。usingディレクティブの効果はusingディレクティブが記述された位置以降のスコープでのみ有効となります。OK}名前空間内で利用するusingディレクティブを独自の名前空間内で利用した場合、取り込まれたメンバは自身の空間内で定義された全ての関数/クラス内で利用可能となります。};}ただし空間内のコードが複雑で膨大になればなるほど、先程挙げた名前衝突やあまいさのリスクが高まります。多重定義された関数が呼ばれなくなる場合がある」で紹介したリスクにも注意する必要があります。無名名前空間/匿名名前空間の場合はファイルスコープへの名前汚染を引き起こしてしまうため注意してください。インライン名前空間でも同様です。活用した独自定義の名前空間に対して、usingディレクティブを用いる際にも注意が必要です。以下のケースでは名前空間libのメンバだけでなく、連鎖的にstdのメンバもファイルスコープやグローバルスコープへ汚染します。