「名前空間stdを使用する」のはなぜですか。悪い習慣だと思いますか?

2776
akbiggs 2009-09-21 17:08.

using namespace std;コードを書くのは間違っているので、代わりに直接使用する必要があるstd::coutと他の人から言われましたstd::cin

なぜusing namespace std;悪い習慣と見なされるのですか?それは非効率的ですか、それともあいまいな変数(std名前空間の関数と同じ名前を共有する変数)を宣言するリスクがありますか?パフォーマンスに影響しますか?

30 answers

2351
Greg Hewgill 2009-09-21 17:13.

これはパフォーマンスとはまったく関係ありません。ただし、これを考慮してください。FooとBarという2つのライブラリを使用しています。

using namespace foo;
using namespace bar;

すべてが正常に機能し、Blah()FooおよびQuux()Barから問題なく電話をかけることができます。しかし、ある日、Foo 2.0の新しいバージョンにアップグレードすると、Quux()。という機能が提供されるようになります。これで競合が発生しました。Foo2.0とBarの両方がQuux()グローバル名前空間にインポートされます。これは、特に関数のパラメーターがたまたま一致する場合、修正するのにいくらかの努力が必要になります。

とを使用foo::Blah()していた場合bar::Quux()、の導入はfoo::Quux()イベントではなかったでしょう。

1442
sbi 2009-09-21 23:26.

「名前空間stdを使用する」のはなぜですか。悪い習慣だと思いますか?すべてに同意します「名前空間stdを使用する」のはなぜですか。悪い習慣だと思いますか?、付け加えたいと思います。グレッグが言ったよりもさらに悪化する可能性があります。

Library Foo 2.0Quux()は、何年にもわたって呼び出されたコードQuux()よりも、いくつかの呼び出しに明確に一致する関数を導入する可能性がありますbar::Quux()。次に、あなたのコードはまだコンパイルしますが、それは静かに間違った関数を呼び出すと、神が、知っている-何を行います。それは物事が得ることができるのと同じくらい悪いです。

ことを覚えておいてくださいstd名前空間があり、その多く識別子のトンがある非常に一般的なもの(だと思うlistsortstringiteratorあまりにも、他のコードに表示される可能性が非常に高い、など)。

これがありそうもないと思うなら:私がこの答えを出した約半年後に、これがほぼ正確に起こった(プレフィックスが省略されたために間違った関数が呼び出された)という質問がStackOverflowでここに尋ねられましたstd::C ++でのポインタと参照に関する混乱は、そのような質問のもう1つの最近の例です。ですから、これは本当の問題です。


もう1つのデータポイントは次のとおりです。何年も前、私は標準ライブラリのすべてにstd::。をプレフィックスとして付ける必要があるのも面倒だと思っていました。それから私は、using関数スコープを除いてディレクティブと宣言の両方が禁止されることが最初に決定されたプロジェクトで働きました。何だと思う?私たちのほとんどは、プレフィックスの記述に慣れるのに非常に数週間かかり、さらに数週間後、実際にコードが読みやすくなることに同意しました。それには理由があります。短い散文と長い散文のどちらが好きかは主観的ですが、接頭辞は客観的にコードを明確にします。コンパイラだけでなく、あなたも、どの識別子が参照されているかを簡単に確認できます。

10年で、そのプロジェクトは数百万行のコードを持つようになりました。これらの議論が何度も出てくるので、私はかつて、(許可された)関数スコープがusing実際にプロジェクトでどのくらいの頻度で使用されているのか興味がありました。私はそれのソースをgrepしましたが、それが使用された場所は1つか2ダースしか見つかりませんでした。私にとってこれは、一度試してみると、std::使用が許可されている場合でも、100kLoCごとに1回でもディレクティブの使用を採用するほど苦痛を感じないことを示しています。


結論:すべてを明示的に接頭辞として付けることは害を及ぼすことはなく、慣れるのにほとんど時間がかからず、客観的な利点があります。特に、コンパイラーと人間の読者がコードを解釈しやすくします。これが、コードを作成する際の主な目標になるはずです。

453
ChrisW 2009-09-21 17:22.

using namespaceクラスのヘッダーファイルを配置する際の問題は、(ヘッダーファイルを含めることによって)クラスを使用したい人は、他の名前空間も「使用」(つまり、すべてを表示)することを余儀なくされることです。

ただし、(プライベート)*。cppファイルにusingステートメントを自由に配置できます。


このように「お気軽に」と言うことに同意しない人もいることに注意してくださいusing。cppファイルのステートメントはヘッダーより優れていますが(ヘッダーファイルを含む人には影響しないため)、まだそうではないと考えているためです。良い(コードによっては、クラスの実装を維持するのが難しくなる可能性があるため)。このC ++ Super-FAQエントリには、次のように書かれています。

usingディレクティブは、レガシーC ++コード用に存在し、名前空間への移行を容易にしますが、少なくとも新しいC ++コードでは、定期的に使用するべきではありません。

FAQは2つの選択肢を提案しています:

  • 使用宣言:

    using std::cout; // a using-declaration lets you use cout without qualification
    cout << "Values:";
    
  • std ::と入力するだけです

    std::cout << "Values:";
    
241
David Thornley 2010-10-29 07:37.

最近、Visual Studio2010に関する苦情に遭遇しました。ほとんどすべてのソースファイルに次の2行が含まれていることが判明しました。

using namespace std;
using namespace boost;

多くのBoost機能がC ++ 0x標準に組み込まれ、Visual Studio2010には多くのC ++ 0x機能があるため、突然これらのプログラムがコンパイルされなくなりました。

したがって、回避using namespace X;は将来を保証する形式であり、使用中のライブラリやヘッダーファイルへの変更がプログラムを壊さないようにする方法です。

216
mattnewport 2014-11-04 10:00.

短いバージョン:usingヘッダーファイルでグローバル宣言またはディレクティブを使用しないでください。実装ファイルで自由に使用してください。ここでは何ハーブサッターアンドレイアレキは、この問題について言っているC ++コーディング規約(強調のために太字は私のものです):

概要

名前空間の使用は、他の人に与えることではなく、ユーザーの便宜のためです。#includeディレクティブの前にusing宣言またはusingディレクティブを記述しないでください。

当然の結果:ヘッダーファイルでは、ディレクティブや宣言を使用して名前空間レベルを記述しないでください。代わりに、すべての名前を明示的に名前空間で修飾します。(2番目のルールは最初のルールに従います。ヘッダーは他のヘッダー#includeがそれらの後に表示される可能性があることを知ることができないためです。)

討論

つまり、実装ファイルで#includeディレクティブの後に宣言とディレクティブを自由に使用して名前空間を使用でき、使用する必要があります。反対の主張が繰り返されているにもかかわらず、宣言とディレクティブを使用した名前空間は悪ではなく、名前空間の目的を損なうことはありません。むしろ、それらは名前空間を使用可能にするものです。

128
robson3.14 2009-09-22 05:47.

using特にヘッダーでは、グローバルスコープでディレクティブを使用しないでください。ただし、ヘッダーファイルでも適切な場合があります。

template <typename FloatType> inline
FloatType compute_something(FloatType x)
{
    using namespace std; // No problem since scope is limited
    return exp(x) * (sin(x) - cos(x * 2) + sin(x * 3) - cos(x * 4));
}

これは、明示的な修飾(std::sinstd::cos...)よりも優れています。これは、短く、ユーザー定義の浮動小数点型(引数依存のルックアップ(ADL)を介して)を処理できるためです。

100
towi 2013-01-18 23:34.

グローバルに使用しないでください

グローバル使用された場合にのみ「不良」と見なさます。理由:

  • プログラミングしている名前空間が乱雑になります。
  • 多くのを使用すると、読者は特定の識別子がどこから来たのかを理解するのが困難になりますusing namespace xyz
  • あなたのソースコードの他の読者に当てはまるものは何でも、それの最も頻繁な読者であるあなた自身にさらに当てはまります。1、2年後に戻ってきて見てください...
  • 話しているだけusing namespace stdでは、取得したものすべてに気付いていない可能性があります。また、別の#includeリビジョンを追加したり、新しいC ++リビジョンに移動したりすると、気づかなかった名前の競合が発生する可能性があります。

ローカルで使用できます

先に進んで、ローカルで(ほぼ)自由に使用してください。もちろん、これはstd::-の繰り返しを防ぎます。繰り返しも悪いです。

ローカルで使用するためのイディオム

C ++ 03には、swapクラスの関数を実装するためのイディオム(定型コード)がありました。実際にローカルを使用することをお勧めしますusing namespace std-または少なくともusing std::swap

class Thing {
    int    value_;
    Child  child_;
public:
    // ...
    friend void swap(Thing &a, Thing &b);
};
void swap(Thing &a, Thing &b) {
    using namespace std;      // make `std::swap` available
    // swap all members
    swap(a.value_, b.value_); // `std::stwap(int, int)`
    swap(a.child_, b.child_); // `swap(Child&,Child&)` or `std::swap(...)`
}

これは次の魔法を行います:

  • コンパイラはstd::swapfor value_、すなわちを選択しますvoid std::swap(int, int)
  • オーバーロードがvoid swap(Child&, Child&)実装されている場合、コンパイラはそれを選択します。
  • その過負荷がない場合、コンパイラーはvoid std::swap(Child&,Child&)これらを使用して最善の交換を試みます。

C ++ 11では、このパターンを使用する理由はもうありません。の実装はstd::swap、潜在的な過負荷を見つけて選択するように変更されました。

81
sth 2009-09-21 17:23.

あなたは右のヘッダファイルをインポートする場合、あなたは突然のような名前持ってhexleftplusまたはcountあなたのグローバルスコープ内に。std::これらの名前が含まれていることに気付いていない場合、これは驚くべきことかもしれません。これらの名前もローカルで使用しようとすると、かなり混乱する可能性があります。

すべての標準的なものが独自の名前空間にある場合は、コードや他のライブラリとの名前の衝突について心配する必要はありません。

52
Martin Beckett 2009-09-21 17:13.

もう一つの理由は驚きです。

私が見るならcout << blahstd::cout << blah私が思う代わりに:これは何coutですか?正常coutですか?何か特別なものですか?

49
Alexander Poluektov 2011-03-29 22:10.

経験豊富なプログラマーは、問題を解決するものは何でも使用し、新しい問題を引き起こすものはすべて回避します。また、この正確な理由から、ヘッダーファイルレベルのusingディレクティブを回避します。

経験豊富なプログラマーは、ソースファイル内の名前の完全な修飾を避けようとします。これのマイナーな理由は、正当な理由がない限り、より少ないコードで十分な場合に、より多くのコードを書くことはエレガントではないということです。これの主な理由は、引数依存ルックアップ(ADL)をオフにすることです。

これらの正当な理由は何ですか?プログラマーが明示的にADLをオフにしたい場合もあれば、明確にしたい場合もあります。

したがって、以下は問題ありません。

  1. 関数の実装内の関数レベルのusingディレクティブとusing宣言
  2. ソースファイル内のソースファイルレベルのusing宣言
  3. (時々)ソースファイルレベルのusingディレクティブ
46
Oleksiy 2013-08-29 23:44.

グローバルに使用すべきではないことに同意しますが、のようにローカルで使用することはそれほど悪いことではありませんnamespace。これが「C ++プログラミング言語」の例です。

namespace My_lib {

    using namespace His_lib; // Everything from His_lib
    using namespace Her_lib; // Everything from Her_lib

    using His_lib::String; // Resolve potential clash in favor of His_lib
    using Her_lib::Vector; // Resolve potential clash in favor of Her_lib

}

この例では、名前の潜在的な衝突と、それらの構成から生じるあいまいさを解決しました。

そこで明示的に宣言された名前(using-declarationsなどで宣言された名前を含むHis_lib::String)は、using-directive(using namespace Her_lib)によって別のスコープでアクセス可能にされた名前よりも優先されます。

32
Yelonek 2009-09-21 23:34.

また、それは悪い習慣だと思います。どうして?ある日、名前空間の機能はものを分割することだと思ったので、すべてを1つのグローバルバッグに投げ込んでそれを台無しにすべきではありません。

ただし、「cout」と「cin」を頻繁に使用する場合using std::cout; using std::cin;は、.cppファイルに次のように記述します(ヘッダーファイルでは伝播しないため#include)。誰も正気の人がストリームcoutやに名前を付けることはないと思いますcin。;)

27
gnasher729 2014-03-14 07:22.

コードを見て、それが何をするのかを知るのは素晴らしいことです。私が見れば、それが図書館の流れstd::coutだとわかってcoutstdます。私が見るならcout、私は知りません。それは図書館の流れかもしれません。または、同じ関数で10行高くなる可能性があります。または、そのファイルで指定された変数。それは何でもかまいません。coutstdint cout = 0;staticcout

ここで、特に大きくない100万行のコードベースを取得します。バグを探しています。つまり、この100万行の中に、本来の機能を果たさない行が1つあることがわかります。名前付きをcout << 1;読み取り、それを1ビット左にシフトして、結果を破棄することができます。バグを探して、それをチェックする必要があります。私が本当に本当に見たいと思っていることがわかりますか?static intcoutstd::cout

あなたが教師であり、生活のためにコードを書いたり維持したりする必要がなかったなら、それは本当に良い考えのように思えるこれらのことの1つです。私はコードを見るのが大好きです。(1)コードの機能を知っています。そして、(2)それを書いている人はそれが何をするのか知っていたと私は確信しています。

25
Preet Sangha 2009-09-21 17:14.

複雑さを管理することがすべてです。名前空間を使用すると、不要なものが引き込まれ、デバッグが困難になる可能性があります(おそらくそう言います)。std ::を使用すると、あらゆる場所で読みにくくなります(より多くのテキストなど)。

コースのための馬-あなたが最善を尽くし、できると感じる方法であなたの複雑さを管理します。

20
Ron Warholic 2009-09-21 17:19.

検討する

// myHeader.h
#include <sstream>
using namespace std;


// someoneElses.cpp/h
#include "myHeader.h"

class stringstream {  // Uh oh
};

これは単純な例であることに注意してください。20個のインクルードとその他のインポートを含むファイルがある場合、問題を理解するために通過する依存関係が大量にあります。さらに悪いことに、競合する定義によっては、他のモジュールで無関係なエラーが発生する可能性があります。

ひどいことではありませんが、ヘッダーファイルやグローバル名前空間で使用しないことで頭痛の種を減らすことができます。非常に限られた範囲でそれを行うことはおそらく大丈夫ですが、私の関数がどこから来ているのかを明確にするために余分な5文字を入力するのに問題はありませんでした。

19
Kevin 2016-09-03 10:06.

懸念を明確にするための具体例。2つのライブラリがfooありbar、それぞれに独自の名前空間がある状況があるとします。

namespace foo {
    void a(float) { /* Does something */ }
}

namespace bar {
    ...
}

ここで、次のように独自のプログラムで一緒に使用するfoobarします。

using namespace foo;
using namespace bar;

void main() {
    a(42);
}

この時点で、すべてが正常です。プログラムを実行すると、「何かをします」。しかし、後で更新barして、次のように変更されたとしましょう。

namespace bar {
    void a(float) { /* Does something completely different */ }
}

この時点で、コンパイラエラーが発生します。

using namespace foo;
using namespace bar;

void main() {
    a(42);  // error: call to 'a' is ambiguous, should be foo::a(42)
}

したがって、「a」がを意味することを明確にするために、いくつかのメンテナンスを行う必要がありますfoo::a。これは望ましくありませんが、幸いなことに、非常に簡単です(コンパイラがあいまいとしてマークfoo::するすべての呼び出しの前に追加するだけaです)。

しかし、代わりにバーが次のように変更された別のシナリオを想像してみてください。

namespace bar {
    void a(int) { /* Does something completely different */ }
}

この時点で、への呼び出しは、「何か」を実行a(42)するbar::a代わりにfoo::a、「まったく異なる何か」を実行する代わりに、突然バインドされます。コンパイラの警告などはありません。あなたのプログラムは、以前とはまったく異なる何かを静かに始めます。

名前空間を使用すると、このようなシナリオのリスクがあります。そのため、人々は名前空間の使用に不快感を覚えます。名前空間に含まれるものが多いほど、競合のリスクが高くなるためstd、他の名前空間よりも(その名前空間に含まれるものの数が多いために)名前空間を使用することはさらに不快になる可能性があります。

最終的に、これは書き込み可能性と信頼性/保守性の間のトレードオフです。読みやすさも考慮に入れるかもしれませんが、私はそれがどちらの方向にも進んでいるという議論を見ることができました。通常、信頼性と保守性の方が重要だと思いますが、この場合、かなりまれな信頼性/保守性の影響に対して、書き込み可能性のコストを常に支払うことになります。「最良の」トレードオフは、プロジェクトと優先順位を決定します。

18
user2645752 2013-11-10 05:09.

同時に多くの名前空間を使用することは明らかに災害のレシピですが、再定義は自分のコードによってのみ発生する可能性があるため、JUST名前空間stdと名前空間のみを使用stdすることは私の意見ではそれほど大きな問題ではありません...

したがって、それらを「int」や「class」などの予約名として機能すると考えてください。それだけです。

人々はそれについてそんなに肛門になるのをやめるべきです。あなたの先生はずっと正しかった。1つの名前空間を使用するだけです。それが、そもそも名前空間を使用することの要点です。同時に複数を使用することは想定されていません。それがあなた自身のものでない限り。繰り返しになりますが、再定義は行われません。

18
Dustin Getz 2009-09-21 18:04.
  1. あなたとは異なるスタイルやベストプラクティスの意見を持つ人々によって書かれたコードを読むことができる必要があります。

  2. のみを使用している場合cout、誰も混乱することはありません。しかし、たくさんの名前空間が飛び交っていて、このクラスが表示され、それが何をするのか正確にわからない場合、名前空間を明示的にすることは、ある種のコメントとして機能します。一見すると、「ああ、これはファイルシステムの操作です」または「ネットワーク関連の処理を行っています」とわかります。

14
Carl 2015-02-12 14:40.

私はここで他の人たちに同意しますが、読みやすさに関する懸念に対処したいと思います-ファイル、関数、またはクラス宣言の先頭でtypedefを使用するだけで、これらすべてを回避できます。

クラス内のメソッドは同様のデータ型(メンバー)を処理する傾向があり、typedefはクラスのコンテキストで意味のある名前を割り当てる機会であるため、通常はクラス宣言で使用します。これは実際には、クラスメソッドの定義を読みやすくするのに役立ちます。

// Header
class File
{
   typedef std::vector<std::string> Lines;
   Lines ReadLines();
}

と実装で:

// .cpp
Lines File::ReadLines()
{
    Lines lines;
    // Get them...
    return lines;
}

とは対照的に:

// .cpp
vector<string> File::ReadLines()
{
    vector<string> lines;
    // Get them...
    return lines;
}

または:

// .cpp
std::vector<std::string> File::ReadLines()
{
    std::vector<std::string> lines;
    // Get them...
    return lines;
}
14
Rohan Singh 2015-04-06 02:56.

名前空間は名前付きスコープです。名前空間は、関連する宣言をグループ化し、個別の項目を個別に保持するために使用されます。たとえば、別々に開発された2つのライブラリが同じ名前を使用して異なるアイテムを参照している場合でも、ユーザーは次の両方を使用できます。

namespace Mylib{
    template<class T> class Stack{ /* ... */ };
    // ...
}

namespace Yourlib{
    class Stack{ /* ... */ };
    // ...
}

void f(int max) {
    Mylib::Stack<int> s1(max); // Use my stack
    Yourlib::Stack    s2(max); // Use your stack
    // ...
}

名前空間名を繰り返すと、リーダーとライターの両方の気が散ることがあります。したがって、特定の名前空間からの名前は、明示的な修飾なしで使用可能であると述べることができます。例えば:

void f(int max) {
    using namespace Mylib; // Make names from Mylib accessible
    Stack<int> s1(max); // Use my stack
    Yourlib::Stack s2(max); // Use your stack
    // ...
}

名前空間は、さまざまなライブラリやさまざまなバージョンのコードを管理するための強力なツールを提供します。特に、非ローカル名への参照を明示的に行う方法の代替案をプログラマーに提供します。

出典: BjarneStroustrupによるC ++プログラミング言語の概要

11
Nithin 2014-12-31 22:00.

using namespace stdカウントのあいまいさのためにコンパイルエラーをスローする例。これはアルゴリズムライブラリの関数でもあります。

#include <iostream>
#include <algorithm>

using namespace std;

int count = 1;
int main() {
    cout << count << endl;
}
10
CryogenicNeo 2018-04-24 07:15.

ソフトウェアやプロジェクトのパフォーマンスを悪化させることはありません。ソースコードの先頭に名前空間を含めることは悪くありません。using namespace std指示が含まれるかどうかは、ニーズやソフトウェアまたはプロジェクトの開発方法によって異なります。

namespace stdは、C ++の標準関数と変数が含まれています。この名前空間は、C ++標準関数を頻繁に使用する場合に役立ちます。

このページで言及されているように:

名前空間stdを使用するステートメントは、一般的に悪い習慣と見なされます。このステートメントの代わりに、型を宣言するたびにスコープ演算子(::)を使用して、識別子が属する名前空間を指定します。

そして、この意見を参照してください:

名前空間を多用し、何も衝突しないことが確実にわかっている場合は、ソースファイルで「usingnamespacestd」を使用しても問題はありません。

using namespace stdその名前空間からすべての関数と変数を呼び出すため、ソースファイルにを含めるのは悪い習慣だと言う人もいます。に含まれている別の関数と同じ名前で新しい関数を定義するnamespace std場合、関数をオーバーロードし、コンパイルまたは実行によって問題が発生する可能性があります。期待どおりにコンパイルまたは実行されません。

このページで言及されているように:

このステートメントを使用すると、std ::と入力する必要がなくなりますが、std名前空間で定義されたクラスまたは型にアクセスする場合は常に、std名前空間全体がプログラムの現在の名前空間にインポートされます。これがそれほど良いことではない理由を理解するために、いくつかの例を見てみましょう

..。

開発の後の段階で、「foo」と呼ばれるライブラリにカスタム実装された別のバージョンのcoutを使用したいと思います(たとえば)

..。

coutが指しているライブラリがあいまいであることに注意してください。コンパイラはこれを検出し、プログラムをコンパイルしない場合があります。最悪の場合、識別子が属する名前空間を指定したことがないため、プログラムはコンパイルされても間違った関数を呼び出す可能性があります。

8
Dr. Watson 2009-09-21 17:34.

すべての条件下で必ずしも悪い習慣だとは思いませんが、使用するときは注意が必要です。ライブラリを作成している場合は、名前空間でスコープ解決演算子を使用して、ライブラリが他のライブラリと頭をぶつけないようにする必要があります。アプリケーションレベルのコードについては、何も問題はありません。

8
Noname 2014-10-14 07:30.

私は他の人に同意します-それは名前の衝突、曖昧さを求めています、そしてそれから事実はそれがあまり明白ではないということです。の使用法はわかりますがusing、個人的な好みはそれを制限することです。また、他の人が指摘したことも強く検討します。

かなり一般的な名前である可能性がある関数名を検索したいが、std名前空間でのみ検索したい場合(またはその逆-名前空間、名前空間、...にないすべての呼び出しを変更したい場合)、では、これをどのように提案しますか?stdX

それを行うためのプログラムを書くこともできますが、プロジェクトを維持するためのプログラムを書くよりも、プロジェクト自体に時間を費やすほうがよいのではないでしょうか。

個人的には、std::プレフィックスは気にしません。私はそれを持っていないよりも見た目が好きです。それが明示的で「これは私のコードではありません...私は標準ライブラリを使用しています」と言っているからなのか、それとも他のものなのかはわかりませんが、見た目は良いと思います。私が最近C ++を始めたばかりであることを考えると、これは奇妙かもしれません(Cや他の言語をずっと長く使用していて、Cはアセンブリのすぐ上で私のお気に入りの言語です)。

上記や他の人の指摘と多少関係がありますが、もう一つあります。これは悪い習慣かもしれませんがstd::name、プログラム固有の実装のために標準ライブラリのバージョンと名前を予約することがあります。はい、確かにこれはあなたを噛み、あなたを激しく噛む可能性がありますが、それはすべて私がこのプロジェクトを最初から始めたということであり、私はそれのための唯一のプログラマーです。例:オーバーロードstd::stringして呼び出しますstring。役立つ追加があります。私のCとUnix(+ Linux)は小文字の名前を好む傾向があるため、私はそれを部分的に行いました。

それ以外に、名前空間エイリアスを持つことができます。これは、参照されていない可能性のある有用な場所の例です。私はC ++ 11標準を使用し、特にlibstdc ++で使用します。まあ、それは完全なstd::regexサポートを持っていません。確かに、それはコンパイルされますが、プログラマー側のエラーであるという行に沿って例外をスローします。しかし、それは実装の欠如です。

これが私がそれを解決した方法です。Boostの正規表現をインストールし、リンクします。次に、libstdc ++で完全に実装されたときに、このブロックを削除するだけでコードが同じになるように、次のようにします。

namespace std
{
    using boost::regex;
    using boost::regex_error;
    using boost::regex_replace;
    using boost::regex_search;
    using boost::regex_match;
    using boost::smatch;
    namespace regex_constants = boost::regex_constants;
}

それが悪い考えであるかどうかについては議論しません。しかし、はそれが私のプロジェクトのためにそれをきれいに保つと同時にそれを具体的にすることを主張します:確かに、私はブーストを使わなければなりません、しかし私はlibstdc ++が最終的にそれを持っているようにそれを使っています。はい、独自のプロジェクトを開始し、最初に標準(...)から開始することは、メンテナンス、開発、およびプロジェクトに関連するすべてのことを支援するのに非常に役立ちます!

何かを明確にするために:STLでクラスの名前を意図的に、より具体的には代わりに使用することは、実際には良い考えではないと思います。「文字列」のアイデアが気に入らなかったので、文字列は私にとって例外です(最初、上記、または2番目を無視し、必要に応じてしゃれます)。

現状では、私はまだCに非常に偏っていて、C ++に偏っています。詳細を控えて、私が取り組んでいることの多くはCにもっと適合します(しかし、それは自分自身をa。別の言語を学び、b。オブジェクト/クラスなどに対して偏見を少なくしないようにするための良い演習であり、良い方法でした。偏見が少なく、傲慢でなく、より受け入れやすいものとして。)しかし、何がある便利なことは、一部が既に提案するものである:私は確かに私が何をした場合、名前が衝突する原因となる2名前を付けるためにソート(同じことを)(?それはかなり一般的で、それはない)リストを使用し、かusing namespace std;、などをそのために、私は具体的で、管理し、それを標準的な使用法にするつもりなら、それを指定しなければならないことを知っていることを好みます。簡単に言えば、許可されているとは限りません。

そして、Boostの正規表現をの一部にすることに関してstd。私は将来の統合のためにそれを行います、そして-繰り返しますが、これはバイアスであることを完全に認めます-私はそれがほど醜いとは思わないboost::regex:: ...。確かに、それは私にとって別のことです。C ++には、外観とメソッドでまだ完全に受け入れられていないことがたくさんあります(別の例:可変個引数テンプレートとvar引数[可変個引数テンプレートは非常に便利です!])。私が受け入れるものでさえそれは困難でした、そして私はまだ彼らに問題を抱えています。

8
Engine Dev 2016-08-21 12:55.

私の経験から、say、を使用するライブラリが複数あるcoutが、目的が異なる場合は、間違っcoutたを使用する可能性があります。

たとえば、(または)ではなく、「using namespace std;and」using namespace otherlib;と「just」cout(たまたま両方にある)と入力すると、間違ったものを使用してエラーが発生する可能性があります。を使用する方がはるかに効果的で効率的です。std::cout'otherlib::cout'std::cout

8
Swiss Frank 2019-05-23 12:05.

ケースバイケースです。ソフトウェアの「総所有コスト」をその存続期間にわたって最小限に抑えたいと考えています。「名前空間stdを使用する」と述べるにはいくらかのコストがかかりますが、それ使用しないと読みやすさにもコストがかかります。

人々は、それを使用するときに、標準ライブラリが新しいシンボルと定義を導入すると、コードのコンパイルが停止し、変数の名前を変更せざるを得なくなる可能性があることを正しく指摘しています。それでも、これはおそらく長期的には良いことです。なぜなら、ある驚くべき目的でキーワードを使用している場合、将来のメンテナは一時的に混乱したり気を散らしたりするからです。

たとえば、他の人に知られているベクターではない、ベクターと呼ばれるテンプレートは必要ありません。そして、このようにC ++ライブラリに導入された新しい定義の数は十分に少ないので、単純に思いつかないかもしれません。そこの変化のこの種を行うに持つのコストは、しかし、コストは高くなく、使用しないことによって得られる明快によって相殺されstd、他の目的のためにシンボル名を。

クラス、変数、および関数の数を考えるとstd::、すべてについて述べると、コードが50%フラフになり、頭を動かすのが難しくなる可能性があります。1画面のコードに取り込むことができるアルゴリズムまたはメソッドのステップでは、フォローするために前後にスクロールする必要があります。これは実際のコストです。おそらくそれは高額ではないかもしれませんが、それが存在することさえ否定する人々は、経験が浅い、独断的、または単に間違っています。

私は次のルールを提供します:

  1. std他のすべてのライブラリとは異なります。これは、基本的に誰もが知っておく必要のある1つのライブラリであり、私の見解では、言語の一部として考えるのが最善です。一般的に言ってusing namespace std、他の図書館がなくても、優れたケースがあります。

  2. これusingをヘッダーに入れて、コンパイルユニット(.cppファイル)の作成者に決定を強制しないでください。決定は常にコンパイルユニットの作成者に任せてください。using namespace stdどこでも使用することを決定したプロジェクトでも、そのルールの例外として最も適切に処理されるいくつかのモジュールに問題がない場合があります。

  3. 名前空間機能を使用すると、シンボルが同じように定義された多くのモジュールを使用できますが、そうすることは混乱を招きます。可能な限り名前を変えてください。名前空間機能を使用していない場合でも、という名前のクラスがあり、という名前のクラスfoostd導入する場合は、fooとにかくクラスの名前を変更する方が長期的にはおそらく良いでしょう。

  4. 名前空間を使用する代わりに、シンボルにプレフィックスを付けて手動で名前空間を付けることもできます。私は何十年も使用してきた2つのライブラリを持っています。どちらもCライブラリとして始まり、実際には、すべてのシンボルの前に「AK」または「SCWin」が付いています。一般的に言えば、これは「使用」構造を回避するようなものですが、ツインコロンは記述しません。AK::foo()代わりにAKFoo()です。これにより、コードの密度が5〜10%低くなり、冗長性が低下します。唯一の欠点は、同じプレフィックスを持つ2つのそのようなライブラリを使用する必要がある場合に大きな問題が発生することです。X Windowライブラリは、いくつかの#definesでそうするのを忘れていることを除いて、この点で優れていることに注意してください。TRUEとFALSEはXTRUEとXFALSEである必要があり、これにより、同様にTRUEとFALSEを使用するSybaseまたはOracleとの名前空間の衝突が設定されます。異なる値で!(データベースの場合はASCII 0および1です!)これの特別な利点の1つは、プリプロセッサ定義に適用されないように見えるのに対し、C ++ using/namespaceシステムはそれらを処理しないことです。これの良い利点は、プロジェクトの一部から最終的にはライブラリになるまでの有機的な傾斜を与えることです。私の大規模なアプリケーションでは、すべてのウィンドウクラスにプレフィックスが付けられWin、すべての信号処理モジュールがModなどになります。これらのいずれかが再利用される可能性はほとんどないため、各グループをライブラリにすることによる実用的なメリットはありませんが、プロジェクトがサブプロジェクトにどのように分割されるかが数秒で明らかになります。

7
August Karlstrom 2013-04-12 04:22.

修飾されていないインポートされた識別子では、識別子が宣言されている場所を見つけるためにgrepなどの外部検索ツールが必要です。これにより、プログラムの正当性についての推論が難しくなります。

7
MathGladiator 2009-09-21 17:15.

それがどこにあるかによります。共通のヘッダーである場合は、名前空間をグローバル名前空間にマージすることにより、名前空間の値を減らしています。これは、モジュールをグローバルにするための優れた方法である可能性があることに注意してください。

7
adn.911 2017-12-01 06:24.

これは悪い習慣であり、しばしばグローバル名前空間汚染として知られています。複数の名前空間が署名付きの同じ関数名を持っている場合、問題が発生する可能性があります。コンパイラがどれを呼び出すかを決定するのはあいまいになりますstd::cout。のような関数呼び出しで名前空間を指定すると、これをすべて回避できます。お役に立てれば。:)

6
Noneyo Getit 2013-06-28 10:33.

あなたの質問に答えるために、私はそれを実際にこのように見ています:多くのプログラマー(すべてではない)が名前空間stdを呼び出します。したがって、名前空間stdにあるものと同じ名前を衝突または使用するものを使用しない習慣を身に付ける必要があります。これは当然のことですが、厳密に言えば、考えられる一貫性のある単語や仮名の数と比べるとそれほど多くはありません。

私は本当に...「これが存在することに依存しないでください」と言うことは、それが存在しないことに依存するようにあなたを設定しているだけです。コードスニペットの借用と修復の問題が常に発生します。ユーザー定義および借用したものを本来あるべき範囲に限定し、グローバルを非常に控えめにします(正直なところ、グローバルは「今すぐコンパイルし、後で正気にする」ための最後の手段である必要があります)。stdを使用すると「cout」と「std :: cout」の両方で機能しますが、stdを使用しないと「std :: cout」でのみ機能するため、先生からのアドバイスは悪いと思います。自分のコードをすべて書くことができるとは限りません。

注:コンパイラーの動作について実際に少し学ぶまでは、効率の問題にあまり焦点を当てないでください。コーディングの経験が少しあれば、優れたコードを単純なものに一般化できることに気付く前に、それらについてそれほど多くを学ぶ必要はありません。まるでCですべてを書いたかのように、あらゆる点で単純です。優れたコードは、必要なだけ複雑です。

Related questions

MORE COOL STUFF

「水曜日」シーズン1の中心には大きなミステリーがあります

「水曜日」シーズン1の中心には大きなミステリーがあります

Netflixの「水曜日」は、典型的な10代のドラマ以上のものであり、実際、シーズン1にはその中心に大きなミステリーがあります.

ボディーランゲージの専門家は、州訪問中にカミラ・パーカー・ボウルズが輝くことを可能にした微妙なケイト・ミドルトンの動きを指摘しています

ボディーランゲージの専門家は、州訪問中にカミラ・パーカー・ボウルズが輝くことを可能にした微妙なケイト・ミドルトンの動きを指摘しています

ケイト・ミドルトンは、州の夕食会と州の訪問中にカミラ・パーカー・ボウルズからスポットライトを奪いたくなかった、と専門家は言う.

一部のファンがハリー・スタイルズとオリビア・ワイルドの「非常に友好的な」休憩が永続的であることを望んでいる理由

一部のファンがハリー・スタイルズとオリビア・ワイルドの「非常に友好的な」休憩が永続的であることを望んでいる理由

一部のファンが、オリビア・ワイルドが彼女とハリー・スタイルズとの間の「難しい」が「非常に友好的」な分割を恒久的にすることを望んでいる理由を見つけてください.

エリザベス女王の死後、ケイト・ミドルトンはまだ「非常に困難な時期」を過ごしている、と王室の専門家が明らかにする 

エリザベス女王の死後、ケイト・ミドルトンはまだ「非常に困難な時期」を過ごしている、と王室の専門家が明らかにする&nbsp;

エリザベス女王の死後、ケイト・ミドルトンが舞台裏で「非常に困難な時期」を過ごしていたと伝えられている理由を調べてください.

セントヘレナのジェイコブのはしごを登るのは、気弱な人向けではありません

セントヘレナのジェイコブのはしごを登るのは、気弱な人向けではありません

セント ヘレナ島のジェイコブズ ラダーは 699 段の真っ直ぐ上る階段で、頂上に到達すると証明書が発行されるほどの難易度です。

The Secrets of Airline Travel Quiz

The Secrets of Airline Travel Quiz

Air travel is far more than getting from point A to point B safely. How much do you know about the million little details that go into flying on airplanes?

Where in the World Are You? Take our GeoGuesser Quiz

Where in the World Are You? Take our GeoGuesser Quiz

The world is a huge place, yet some GeoGuessr players know locations in mere seconds. Are you one of GeoGuessr's gifted elite? Take our quiz to find out!

バイオニック読書はあなたをより速く読むことができますか?

バイオニック読書はあなたをより速く読むことができますか?

BionicReadingアプリの人気が爆発的に高まっています。しかし、それは本当にあなたを速読術にすることができますか?

Total War:Warhammer:Kotakuレビュー

Total War:Warhammer:Kotakuレビュー

私はこのゲームを嫌う準備ができていました。先週の前に、Total War:Warhammerについての私の考えがありました:それでもここに私は、私の手にある完成品であり、私は変わった男です。

涙の道:軍事化された帝国主義勢力がスタンディングロックキャンプを占領

涙の道:軍事化された帝国主義勢力がスタンディングロックキャンプを占領

スタンディングロックスー族のメンバーと水の保護者は、ノースダコタ州のスタンディングロックにあるオセティサコウィンキャンプを去ります。(Twitter経由のCNNスクリーンショット)火と煙がスカイラインを覆い、スタンディングロックスー族のメンバーと水の保護者が、聖なるものを守りながら建てた家、オセティサコウィン(セブンカウンシルファイアーズ)キャンプから行進し、太鼓を打ち、歌い、祈りました。ダコタアクセスパイプラインとしても知られる「ブラックスネーク」からの土地。

シアーズとKマートはイヴァンカ・トランプの商品を自分たちで取り除いています

シアーズとKマートはイヴァンカ・トランプの商品を自分たちで取り除いています

写真:APシアーズとKマートは、イヴァンカ・トランプのトランプホームアイテムのコレクションも、誰も購入したくないために削除しました。シアーズとKマートの両方の親会社であるシアーズホールディングスは、土曜日のABCニュースへの声明で、彼らが気にかけていると辛抱強く説明しましたトランプラインを売り続けるにはお金を稼ぐことについてあまりにも多く。

ポテトチップスでたった10分でスペインのトルティーヤを作る

ポテトチップスでたった10分でスペインのトルティーヤを作る

伝統的なスペインのトルティーヤは通常、オリーブオイルで柔らかくなるまで調理されたポテトから始まります(30分以上かかる場合があります)が、ケトルで調理されたポテトチップスの助けを借りてわずか10分でテーブルに置くことができます。上のビデオはすべてがバラバラにならないように裏返す方法を含め、レシピ全体を説明しますが、必要なのは4〜5個の卵と3カップのケトルチップスだけです。

ケイト・ミドルトンとウィリアム王子は、彼らが子供たちと行っているスパイをテーマにした活動を共有しています

ケイト・ミドルトンとウィリアム王子は、彼らが子供たちと行っているスパイをテーマにした活動を共有しています

ケイト・ミドルトンとウィリアム王子は、子供向けのパズルの本の序文を書き、ジョージ王子、シャーロット王女、ルイ王子と一緒にテキストを読むと述べた.

事故で押しつぶされたスイカは、動物を喜ばせ水分補給するために野生生物保護団体に寄付されました

事故で押しつぶされたスイカは、動物を喜ばせ水分補給するために野生生物保護団体に寄付されました

Yak's Produce は、数十個のつぶれたメロンを野生動物のリハビリ専門家であるレスリー グリーンと彼女のルイジアナ州の救助施設で暮らす 42 匹の動物に寄付しました。

デミ・ロヴァートは、新しいミュージシャンのボーイフレンドと「幸せで健康的な関係」にあります: ソース

デミ・ロヴァートは、新しいミュージシャンのボーイフレンドと「幸せで健康的な関係」にあります: ソース

8 枚目のスタジオ アルバムのリリースに向けて準備を進めているデミ ロヴァートは、「スーパー グレート ガイ」と付き合っている、と情報筋は PEOPLE に確認しています。

Plathville の Kim と Olivia Plath が数年ぶりに言葉を交わすことへようこそ

Plathville の Kim と Olivia Plath が数年ぶりに言葉を交わすことへようこそ

イーサン プラスの誕生日のお祝いは、TLC のウェルカム トゥ プラスビルのシーズン 4 のフィナーレで、戦争中の母親のキム プラスと妻のオリビア プラスを結びつけました。

仕事の生産性を高める 8 つのシンプルなホーム オフィスのセットアップのアイデア

仕事の生産性を高める 8 つのシンプルなホーム オフィスのセットアップのアイデア

ホームオフィスのセットアップ術を極めよう!AppExert の開発者は、家族全員が一緒にいる場合でも、在宅勤務の技術を習得しています。祖父や曽祖父が共同家族で暮らしていた頃の記憶がよみがえりました。

2022 年、私たちのデジタル ライフはどこで終わり、「リアル ライフ」はどこから始まるのでしょうか?

20 年前のタイムトラベラーでさえ、日常生活におけるデジタルおよびインターネットベースのサービスの重要性に驚くことでしょう。MySpace、eBay、Napster などのプラットフォームは、高速化に焦点を合わせた世界がどのようなものになるかを示してくれました。

ニューロマーケティングの秘密科学

ニューロマーケティングの秘密科学

マーケティング担当者が人間の欲望を操作するために使用する、最先端の (気味が悪いと言う人もいます) メソッドを探ります。カートをいっぱいにして 3 桁の領収書を持って店を出る前に、ほんの数点の商品を買いに行ったことはありませんか? あなたは一人じゃない。

地理情報システムの日: GIS 開発者として学ぶべき最高の技術スタック

地理情報システムの日: GIS 開発者として学ぶべき最高の技術スタック

私たちが住んでいる世界を確実に理解するには、データが必要です。ただし、空間参照がない場合、このデータは地理的コンテキストがないと役に立たなくなる可能性があります。

Language