为什么“使用名称空间std”被认为是糟糕的实践?

I've been told by others that writing using namespace std in code is wrong, and that I should use std::cout and std::cin directly instead.

其他人告诉我，在代码中使用名称空间std是错误的，我应该使用std::cout和std::直接使用cin。

Why is using namespace std considered a bad practice? Is it inefficient or does it risk declaring ambiguous variables (variables that share the same name as a function in std namespace)? Does it impact performance?

为什么使用名称空间std被认为是一个糟糕的实践?它是低效的还是有声明含糊的变量(在std名称空间中与函数同名的变量)?影响性能吗?

34 个解决方案

#1

This is not related to performance at all. But consider this: you are using two libraries called Foo and Bar:

这与性能无关。但是考虑一下:您正在使用两个名为Foo和Bar的库:

using namespace foo;
using namespace bar;

Everything works fine, you can call Blah() from Foo and Quux() from Bar without problems. But one day you upgrade to a new version of Foo 2.0, which now offers a function called Quux(). Now you've got a conflict: Both Foo 2.0 and Bar import Quux() into your global namespace. This is going to take some effort to fix, especially if the function parameters happen to match.

一切正常，您可以在没有问题的情况下从Foo和Quux()中调用Blah()。但是有一天，您升级到新的Foo 2.0版本，它现在提供了一个名为Quux()的函数。现在您有了一个冲突:Foo 2.0和Bar导入Quux()到您的全局名称空间中。这将需要一些努力来修复，特别是如果函数参数恰好匹配。

If you had used foo::Blah() and bar::Quux(), then the introduction of foo::Quux() would have been a non-event.

如果您使用过foo::Blah()和bar::Quux()，那么引入foo::Quux()将是一个非事件。

#2

I agree with everything Greg wrote, but I'd like to add: It can even get worse than Greg said!

我同意格雷格写的所有东西，但我想补充一句:它甚至比格雷格说的还要糟糕!

Library Foo 2.0 could introduce a function, Quux(), that is an unambiguously better match for some of your calls to Quux() than the bar::Quux() your code called for years. Then your code still compiles, but it silently calls the wrong function and does god-knows-what. That's about as bad as things can get.

库Foo 2.0可以引入一个函数Quux()，这是对您对Quux()的一些调用比bar::Quux()您的代码需要数年的更好的匹配。然后，你的代码仍然在编译，但它会悄悄地调用错误的函数，并执行上帝所知道的事情。这是很糟糕的事情。

Keep in mind that the std namespace has tons of identifiers, many of which are very common ones (think list, sort, string, iterator, etc.) which are very likely to appear in other code, too.

请记住，std名称空间有大量的标识符，其中许多是非常常见的标识符(如列表、排序、字符串、迭代器等)，它们也很可能出现在其他代码中。

If you consider this unlikely: There was a question asked here on Stack Overflow where pretty much exactly this happened (wrong function called due to omitted std:: prefix) about half a year after I gave this answer. Here is another, more recent example of such a question. So this is a real problem.

如果你认为这是不可能的:在我给出这个答案的大约半年后，在Stack Overflow上有一个问题，几乎就是这个问题(由于省略了std::前缀)。这是另一个最近的例子。所以这是一个真正的问题。

---

Here's one more data point: Many, many years ago, I also used to find it annoying having to prefix everything from the standard library with std::. Then I worked in a project where it was decided at the start that both using directives and declarations are banned except for function scopes. Guess what? It took most of us very few weeks to get used to writing the prefix, and after a few more weeks most of us even agreed that it actually made the code more readable. There's a reason for that: Whether you like shorter or longer prose is subjective, but the prefixes objectively add clarity to the code. Not only the compiler, but you, too, find it easier to see which identifier is referred to.

这里还有一个数据点:许多年前，我还常常发现，在标准库和std之间添加前缀是很烦人的::。然后我在一个项目中工作，在这个项目中，开始使用指令和声明都被禁用，除了函数作用域。你猜怎么着?我们大多数人花了几周的时间才习惯了写前缀，而在几周之后，我们中的大多数人甚至同意，它实际上让代码更容易读懂。这其中有一个原因:您是否喜欢更短的或更长的散文是主观的，但是前缀客观地增加了代码的清晰度。不仅是编译器，而且您也发现更容易看到哪个标识符被引用。

In a decade, that project grew to have several million lines of code. Since these discussions come up again and again, I once was curious how often the (allowed) function-scope using actually was used in the project. I grep'd the sources for it and only found one or two dozen places where it was used. To me this indicates that, once tried, developers don't find std:: painful enough to employ using directives even once every 100 kLoC even where it was allowed to be used.

在十年内，这个项目发展到有几百万行代码。由于这些讨论一次又一次地出现，我曾经很好奇，在项目中使用的(允许的)功能范围使用的频率是多少。我为它找到了来源，只找到了一个或二十多个使用它的地方。对我来说，这表明，一旦尝试，开发人员就不会发现std::即使在允许使用指令的情况下，即使每100 kLoC使用指令，也会非常痛苦。

---

Bottom line: Explicitly prefixing everything doesn't do any harm, takes very little getting used to, and has objective advantages. In particular, it makes the code easier to interpret by the compiler and by human readers — and that should probably be the main goal when writing code.

底线:明确的前缀不会造成任何伤害，只需要很少的习惯，并且有客观的优势。特别是，它使代码更容易由编译器和人类读者来解释——这可能是编写代码时的主要目标。

#3

I think it's bad to put it in the header files of your classes: because then you would be forcing anyone who wants to use your classes (by including your header files) to also be 'using' (i.e. seeing everything in) those other namespaces.

我认为把它放在类的头文件中是不好的:因为这样你就会强迫任何想使用你的类的人(包括你的头文件)也要“使用”(即看到所有的东西)这些其他的名称空间。

However, you may feel free to put a using statement in your (private) *.cpp files.

但是，您可以在您的(私有)*中使用using语句。cpp文件。

---

Beware that some people disagree with my saying "feel free" like this -- because although a using statement in a cpp file is better than in a header (because it doesn't affect people who include your header file), they think it's still not good (because depending on the code it could make the implementation of the class more difficult to maintain). This FAQ topic says,

当心,一些人不同意我这样说“随意”——因为尽管使用cpp文件中声明比一个头(因为它不影响的人包括你的头文件),他们仍认为这是不好的(因为根据类的代码会使实现更难以维护)。这FAQ的话题说,

The using-directive exists for legacy C++ code and to ease the transition to namespaces, but you probably shouldn’t use it on a regular basis, at least not in your new C++ code.

用于遗留c++代码和简化向名称空间转换的指令，但是您可能不应该经常使用它，至少在您的新c++代码中不应该使用它。

It suggests two alternatives:

这表明两种选择:

• A using declaration:

  使用声明:

  using std::cout; // a using-declaration lets you use cout without qualification
  cout << "Values:";
  

• Get over it and just type std::

  Get over it and just type std::

  std::cout << "Values:";
  

#4

I recently ran into a complaint about Visual Studio 2010. It turned out that pretty much all the source files had these two lines:

最近我遇到了一个关于Visual Studio 2010的投诉。原来几乎所有的源文件都有这两行:

using namespace std;
using namespace boost;

A lot of Boost features are going into the C++0x standard, and Visual Studio 2010 has a lot of C++0x features, so suddenly these programs were not compiling.

很多Boost特性都进入了c++ 0x标准，Visual Studio 2010有很多c++ 0x特性，所以这些程序突然没有编译。

Therefore, avoiding using namespace X; is a form of future-proofing, a way of making sure a change to the libraries and/or header files in use is not going to break a program.

因此，避免使用名称空间X;是一种未来验证的形式，一种确保对库和/或头文件进行更改的方法不会破坏程序。

#5

Short version: don't use global using declarations or directives in header files. Feel free to use them in implementation files. Here's what Herb Sutter and Andrei Alexandrescu have to say about this issue in C++ Coding Standards (bolding for emphasis is mine):

短版本:不要在头文件中使用全局声明或指令。可以在实现文件中使用它们。以下是Herb Sutter和Andrei alexrescu在c++编码标准中对这个问题的看法(强调是我的):

Summary

Namespace usings are for your convenience, not for you to inflict on others: Never write a using declaration or a using directive before an #include directive.

命名空间使用是为了您的方便，而不是为了您对他人施加影响:在#include指令之前，不要使用声明或使用指令。

Corollary: In header files, don’t write namespace-level using directives or using declarations; instead, explicitly namespace-qualify all names. (The second rule follows from the first, because headers can never know what other header #includes might appear after them.)

推论:在头文件中，不要使用指令或使用声明来写名称空间级;相反，显式名称空间限定所有名称。(第二个规则来自第一个规则，因为header永远不知道其他的header #include可能会出现在它们后面。)

Discussion

In short: You can and should use namespace using declarations and directives liberally in your implementation files after #include directives and feel good about it. Despite repeated assertions to the contrary, namespace using declarations and directives are not evil and they do not defeat the purpose of namespaces. Rather, they are what make namespaces usable.

简而言之:您可以并且应该使用名称空间，在您的实现文件中使用声明和指令，在包含指示之后，并感觉良好。尽管有相反的断言，使用声明和指令的名称空间并不是邪恶的，它们不会破坏名称空间的目的。相反，它们是使名称空间可用的原因。

#6

One shouldn't use using directive at global scope, especially in headers. However there are situations where it is appropriate even in a header file:

我们不应该在全局范围内使用指令，尤其是在头文件中。然而，即使在头文件中也有适当的情况:

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));
}

This is better than explicit qualification (std::sin, std::cos...) because it is shorter and has the ability to work with user defined floating point types (via Argument Dependent Lookup).

这比显式的限定要好(std::sin, std::cos.)，因为它更短，并且有能力处理用户定义的浮点类型(通过参数依赖查找)。

#7

Do not use it globally

It is considered "bad" only when used globally. Because:

只有在全球使用时，它才被认为是“坏的”。因为:

• You clutter the namespace you are programming in.
• 您将编程的名称空间打乱。
• Readers will have difficulty seeing where a particular identifier comes from, when you use many using namespace xyz.
• 当您使用许多使用名称空间xyz时，读者很难看到一个特定的标识符来自哪里。
• Whatever is true for other readers of your source code is even more true for the most frequent reader of it: yourself. Come back in a year or two and take a look...
• 对于你的源代码的其他读者来说，任何事情都是真实的，对于最经常阅读的读者来说更是如此:你自己。一两年后再来看看……
• If you only talk about using namespace std you might not be aware of all the stuff you grab -- and when you add another #include or move to a new C++ revision you might get name conflicts you were not aware of.
• 如果您只讨论使用名称空间std，您可能不会注意到您所获取的所有内容——当您添加另一个#include或移动到一个新的c++版本时，您可能会遇到您不知道的名称冲突。

You may use it locally

Go ahead and use it locally (almost) freely. This, of course, prevents you from repetition of std:: -- and repetition is also bad.

在本地(几乎)*地使用它。当然，这可以防止您重复std::——而且重复也很糟糕。

An idiom for using it locally

In C++03 there was an idiom -- boilerplate code -- for implementing a swap function for your classes. It was suggested that you actually use a local using namespace std -- or at least using std::swap:

在c++ 03中有一个成语——样板代码——用于实现类的交换函数。建议您实际使用一个本地使用名称空间std——或者至少使用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(...)`
}

This does the following magic:

这就是魔术:

• The compiler will choose the std::swap for value_, i.e. void std::swap(int, int).
• 编译器将选择std::交换value_，即void std::swap(int, int)。
• If you have an overload void swap(Child&, Child&) implemented the compiler will choose it.
• 如果你有一个重载的空交换(Child&， Child&)，编译器会选择它。
• If you do not have that overload the compiler will use void std::swap(Child&,Child&) and try its best swapping these.
• 如果您没有重载，编译器将使用void std::swap(Child&，Child&)，并尝试将其转换为最佳。

With C++11 there is no reason to use this pattern any more. The implementation of std::swap was changed to find a potential overload and choose it.

使用c++ 11，就没有理由再使用这种模式了。std::swap的实现是为了找到一个潜在的重载并选择它。

#8

If you import the right header files you suddenly have names like hex, left, plus or count in your global scope. This might be surprising if you are not aware that std:: contains these names. If you also try to use these names locally it can lead to quite some confusion.

如果您导入正确的头文件，您会突然有像十六进制，左边，加或在您的全局范围内的名称。如果您不知道std::包含这些名称，这可能会令人惊讶。如果您还尝试在本地使用这些名称，可能会引起相当大的混乱。

If all the standard stuff is in its own namespace you don't have to worry about name collisions with your code or other libraries.

如果所有的标准内容都在自己的名称空间中，那么您不必担心名称与代码或其他库的冲突。

#9

I agree that it should not be used globally, but it's not so evil to to use locally, like in a namespace. Here's an example from "The C++ Programming Language" :

我同意它不应该在全球使用，但在本地使用并不是那么邪恶，就像在名称空间中一样。这里有一个来自“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 * in favor of His_lib
    using Her_lib::Vector; // resolve potential * in favor of Her_lib

}

In this example, we resolved potential name *es and ambiguities arising from their composition.

在这个例子中，我们解决了潜在的名称冲突和由于它们的组合而产生的歧义。

Names explicitly declared there (including names declared by using-declarations like His_lib::String) take priority over names made accessible in another scope by a using-directive (using namespace Her_lib).

在那里显式声明的名称(包括像他的_lib::String)这样的使用声明声明的名称，优先于使用一个使用指令(使用名称空间Her_lib)在另一个范围内访问的名称。

#10

Experienced programmers use whatever solves their problems and avoid whatever creates new problems. Thus they avoid header-file-level using-directives for obvious reason.

有经验的程序员使用任何解决他们问题的方法，避免产生新的问题。因此，它们避免了由于明显的原因而使用的header-文件级别的使用指令。

And they try to avoid full qualification of names inside their source files. A minor point is that it's not elegant to write more code when less code suffice without good reason. A major point is turning off ADL.

并且他们试图避免在他们的源文件中完全限定名字。次要的一点是，如果没有充分的理由就编写更多的代码，那么编写更多的代码就不那么优雅了。一个关键点是关闭ADL。

What are these good reasons? Sometimes you explicitly want turning off ADL. Sometimes you want to disambiguate.

这些理由是什么?有时你明确地想要关闭ADL。有时你想消除歧义。

So the following are OK:

所以下面是可以的:

1. Function-level using-directives and using-declarations inside functions' implementations
2. 函数级的使用指令和函数实现中的使用声明。
3. Source-file-level using-declarations inside source files
4. 源文件中的源文件级别的使用声明。
5. (Sometimes) source-file-level using-directives
6. (有时)source-file-level using引用

#11

Another reason is surprise.

另一个原因是意外。

If I see cout << blah, instead of std::cout << blah

如果我看到cout << blah，而不是std::cout << blah。

I think what is this cout? Is it the normal cout? Is it something special?

这个cout是什么?是正常的cout吗?这是一些特别的东西吗?

#12

I also consider it a bad practice. Why? Just one day I thought that function of a namespace is to divide stuff so I shouldn't spoil it with throwing everything into one global bag. However, if I often use 'cout' and 'cin', I write: using std::cout; using std::cin; in cpp file (never in header file as it propagates with #include). I think that noone sane will ever name a stream cout or cin. ;)

我也认为这是一种不好的做法。为什么?有一天，我认为命名空间的功能就是把东西分开，所以我不应该把所有东西都扔进一个全局包里。然而，如果我经常使用“cout”和“cin”，我就会用std::cout;使用std::cin;在cpp文件中(当它与#include一起传播时，不要在头文件中)。我想没有人会说出一个叫cout或cin的名字。,)

#13

It's all about managing complexity. Using the namespace will pull things in that you don't want, and thus possibly make it harder to debug (I say possibly). Using std:: all over the place is harder to read (more text and all that).

这都是关于管理复杂性。使用名称空间将会拉出您不想要的东西，因此可能会使调试变得更加困难(我可能会说)。使用std::所有的地方都很难阅读(更多的文本和所有这些)。

Horses for courses - manage your complexity how you best can and feel able.

课程的马-管理你的复杂性如何你最好的可以和感觉能力。

#14

It's nice to see code and know what it does. If I see std::cout I know that's the cout stream of the std library. If I see cout then I don't know. It could be the cout stream of the std library. Or there could be an int cout = 0; ten lines higher in the same function. Or a static variable named cout in that file. It could be anything.

很高兴看到代码并知道它是干什么的。如果我看到std::cout，我知道那是std库的cout流。如果我看到cout，我就不知道了。它可以是std库的cout流。也可以是int cout = 0;在同一函数中有10行高。或在该文件中名为cout的静态变量。它可以是任何东西。

Now take a million line code base, which isn't particularly big, and you're searching for a bug, which means you know there is one line in this one million lines that doesn't do what it is supposed to do. cout << 1; could read a static int named cout, shift it to the left by one bit, and throw away the result. Looking for a bug, I'd have to check that. Can you see how I really really prefer to see std::cout?

现在，用一百万行代码库，它不是特别大，你正在寻找一个bug，这意味着你知道在这一百万行中有一行没有做它应该做的事情。cout < < 1;可以读取一个名为cout的静态int，将其向左移动一点，然后将结果丢弃。我在找虫子，我得检查一下。你能看出我是多么喜欢std::cout吗?

It's one of these things that seem a really good idea if you are a teacher and never had to write and maintain any code for a living. I love seeing code where (1) I know what it does; and, (2) I'm confident that the person writing it knew what it does.

如果你是一名教师，而且从来不用编写和维护任何生活的代码，这是一个非常好的想法。我喜欢看到代码(1)我知道它的作用;(2)我相信写它的人知道它的作用。

#15

1. you need to be able to read code written by people who have different style and best practices opinions than you.

   你需要能够阅读那些与你有不同风格和最佳实践观点的人写的代码。

2. If you're only using cout, nobody gets confused. But when you have lots of namespaces flying around and you see this class and you aren't exactly sure what it does, having the namespace explicit acts as a comment of sorts. You can see at first glance, 'oh, this is a filesystem operation' or 'thats doing network stuff'.

   如果你只使用cout，没有人会感到困惑。但是当你有很多命名空间的时候，你会看到这个类，而且你也不确定它是干什么的，把命名空间显式作为一个注释。你一眼就能看到，‘噢，这是一个文件系统操作’或者‘这是在做网络工作’。

#16

Consider

考虑

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


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

class stringstream {  // uh oh
};

Note that this is a simple example, if you have files with 20 includes and other imports you'll have a ton of dependencies to go through to figure out the problem. The worse thing about it is that you can get unrelated errors in other modules depending on the definitions that conflict.

请注意，这是一个简单的示例，如果您有包含20个include和其他导入的文件，那么您将有大量的依赖项来解决这个问题。更糟糕的是，根据冲突的定义，您可以在其他模块中获得不相关的错误。

It's not horrible but you'll save yourself headaches by not using it in header files or the global namespace. It's probably alright to do it in very limited scopes but I've never had a problem typing the extra 5 characters to clarify where my functions are coming from.

它并不可怕，但是您可以通过不在头文件或全局名称空间中使用它来避免头痛。在非常有限的范围内这样做可能是对的，但我从来没有遇到过输入额外的5个字符来阐明我的函数来自哪里的问题。

#17

Using many namespaces at the same time is obviously a recipe for disaster, but using JUST namespace std and only namespace std is not that big of a deal in my opinion because redefinition can only occur by your own code...

同时使用多个名称空间显然是一种灾难的方法，但是使用名称空间std和只使用名称空间std在我看来并不是什么大问题，因为重新定义只能由您自己的代码来实现……

So just consider them functions as reserved names like "int" or "class" and that is it.

因此，只要把它们当作保留名称，比如“int”或“class”，就可以了。

People should stop being so anal about it. Your teacher was right all along. Just use ONE namespace; that is the whole point of using namespaces the first place. You are not supposed to use more than one at the same time. Unless it is your own. So again, redefinition will not happen.

人们不应该再这么挑剔了。你的老师一直都是对的。只使用一个名称空间;这就是使用名称空间的第一个地方。你不应该同时使用多于一个。除非是你自己的。再一次，重新定义不会发生。

#18

A concrete example to clarify the concern. Imagine you have a situation where you have 2 libraries, foo and bar, each with their own namespace:

一个具体的例子来阐明这个问题。假设您有两个库、foo和bar，每个都有各自的名称空间:

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

namespace bar {
    ...
}

Now let's say you use foo and bar together in your own program as follows:

现在假设你在自己的程序中使用foo和bar:

using namespace foo;
using namespace bar;

void main() {
    a(42);
}

At this point everything is fine. When you run your program it 'does something'. But later you update bar and let's say it has changed to be like:

在这一点上一切都很好。当你运行程序时，它会“做一些事情”。但是后来你更新了bar，假设它变成了:

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

At this point you'll get a compiler error:

此时，您将得到一个编译器错误:

using namespace foo;
using namespace bar;

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

So you'll need to do some maintenance to clarify which 'a' you meant (i.e. foo::a). That's probably undesirable, but fortunately it is pretty easy (just add foo:: in front of all calls to a that the compiler marks as ambiguous).

因此，您需要做一些维护来澄清您的意思(即foo::a)。这可能是不可取的，但幸运的是，这很简单(只需添加foo::在所有调用的前面，编译器标记为不明确的)。

But imagine an alternative scenario where bar changed instead to look like this instead:

但是想象一下另一种情况，在这里，bar变成了这个样子:

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

At this point your call to a(42) suddenly binds to bar::a instead of foo::a and instead of doing 'something' it does 'something completely different'. No compiler warning or anything. Your program just silently starts doing something complete different than before.

这时，你对a(42)的呼叫突然被绑定到bar::a而不是foo: a，而不是“something”，它做的是“完全不同的事情”。没有编译器警告之类的。你的程序只是默默地开始做与以前完全不同的事情。

When you use a namespace you're risking a scenario like this, which is why people are uncomfortable using namespaces. The more things in a namespace the greater the risk of conflict, so people might be even more uncomfortable using namespace std (due to the number of things in that namespace) than other namespaces.

当您使用名称空间时，您可能会面临这样的场景，这就是为什么人们不喜欢使用名称空间。名称空间中的东西越多，冲突的风险越大，因此，使用名称空间std(由于名称空间中的事物的数量)比其他名称空间更让人感到不舒服。

Ultimately this is a trade-off between writability vs reliability/maintainability. Readability may factor in also, but I could see arguments for that going either way. Normally I would say reliability and maintainability are more important, but in this case you'll constantly pay the writability cost for an fairly rare reliability/maintainability impact. The 'best' trade-off will determine on your project and your priorities.

最终，这是可写性与可靠性/可维护性之间的权衡。可读性可能也会影响到，但我可以看到这两种方式的论证。通常情况下，我认为可靠性和可维护性更重要，但在这种情况下，您将不断地为相当罕见的可靠性/可维护性影响支付可写性成本。“最好”的权衡将决定你的项目和你的优先事项。

#19

A namespace is a named scope. Namespaces are used to group related declarations and to keep separate items separate. For example, two separately developed libraries may use the same name to refer to different items, but a user can still use both:

名称空间是一个命名的范围。名称空间用于对相关的声明进行分组，并将单独的项分隔开。例如，两个单独开发的库可以使用相同的名称来引用不同的项目，但是用户仍然可以同时使用这两个名称:

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
    / / ...
}

Repeating a namespace name can be a distraction for both readers and writers. Consequently, it is possible to state that names from a particular namespace are available without explicit qualification. For example:

重复名称空间名称可能会分散读者和作者的注意力。因此，可以在没有显式限定的情况下声明来自特定名称空间的名称。例如:

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
    / / ...
}

Namespaces provide a powerful tool for the management of different libraries and of different versions of code. In particular, they offer the programmer alternatives of how explicit to make a reference to a nonlocal name.

名称空间为管理不同的库和不同版本的代码提供了强大的工具。特别是，它们为程序员提供了如何显式地引用非本地名称的替代方法。

Source : An Overview of the C++ Programming Language by Bjarne Stroustrup

来源:Bjarne Stroustrup对c++编程语言的概述。

#20

I agree with the others here, but would like to address the concerns regarding readability - you can avoid all of that by simply using typedefs at the top of your file, function or class declaration.

我同意这里的其他内容，但希望解决关于可读性的问题——您可以通过在文件、函数或类声明的顶部使用typedef来避免所有这些问题。

I usually use it in my class declaration as methods in a class tend to deal with similar data types (the members) and a typedef is an opportunity to assign a name that is meaningful in the context of the class. This actually aids readability in the definitions of the class methods.

我通常在类声明中使用它，因为类中的方法倾向于处理相似的数据类型(成员)，而typedef是在类的上下文中指定有意义的名称的机会。这实际上有助于提高类方法定义的可读性。

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

and in the implementation:

和实现:

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

as opposed to:

而不是:

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

or:

或者:

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

#21

An example where using namespace std throws complilation error because of the ambiguity of count, which is also a function in algorithm library.

一个使用命名空间std的例子，由于count的模糊性，导致了一致性错误，这也是算法库中的一个函数。

#include <iostream>

using namespace std;

int count = 1;
int main() {
    cout<<count<<endl;
}

#22

I do not think it is necessarily bad practice under all conditions, but you need to be careful when you use it. If you're writing a library, you probably should use the scope resolution operators with the namespace to keep your library from butting heads with other libraries. For application level code, I don't see anything wrong with it.

我不认为在所有的情况下都是不好的做法，但是当你使用它的时候你要小心。如果您正在编写一个库，您可能应该使用带有名称空间的范围解析操作符来保持您的库与其他库的连接。对于应用程序级别的代码，我没有发现任何错误。

#23

"Why is 'using namespace std;' considered a bad practice in C++?"

“为什么‘使用名称空间std’被认为是c++中的一个糟糕的实践?”

I put it the other way around: Why is typing 5 extra chars is considered cumbersome by some?

我用另一种方式来解释:为什么要输入5个额外的字符被一些人认为是很麻烦的?

Consider e.g. writing a piece of numerical software, why would I even consider polluting my global namespace by cutting general "std::vector" down to "vector" when "vector" is one of the problem domain's most important concepts?

考虑一下，比如写一个数字软件，为什么我甚至会考虑将“std::vector”这个词放在“vector”的位置，从而污染我的全局命名空间，而“vector”是问题领域最重要的概念之一?

#24

With unqualified imported identifiers you need external search tools like grep to find out where identifiers are declared. This makes reasoning about program correctness harder.

使用不合格的导入标识符，您需要像grep这样的外部搜索工具来查找标识符的位置。这使得对程序正确性的推理更加困难。

#25

To answer your question I look at it this way practically: a lot of programmers (not all) invoke namespace std. Therefore one should be in the habit of NOT using things that impinge or use the same names as what is in the namespace std. That is a great deal granted, but not so much compared to the number of possible coherent words and pseudonyms that can be come up with strictly speaking.

这样回答你的问题我看实际上:很多程序员(不是全部)调用命名空间性病。因此,你应该不使用的东西的习惯,侵犯或使用相同的名称作为名称空间性病是什么。这是一个伟大的交易,但是没有那么多的数量相比可能连贯的文字和假名,可以严格地说。

I mean really... saying "don't rely on this being present" is just setting you up to rely on it NOT being present. You are constantly going to have issues borrowing code snippets and constantly repairing them. Just keep your user-defined and borrowed stuff in limited scope as they should be and be VERY sparing with globals (honestly globals should almost always be a last resort for purposes of "compile now, sanity later"). Truly I think it is bad advice from your teacher because using std will work for both "cout" and "std::cout" but NOT using std will only work for "std::cout". You will not always be fortunate enough to write all your own code.

我的意思是真的……说“不要依赖现在”只是让你依赖它而不是现在。您经常会遇到一些问题，比如借用代码片段并不断地修复它们。只需要将用户定义的和借来的东西放在有限的范围内，就像它们应该那样，并且与全局变量保持一致(诚实地说，globals应该是“现在编译，以后明智”的最后手段)。我真的认为这是老师不好的建议，因为使用std会对“cout”和“std::cout”起作用，但不使用std只适用于“std::cout”。你不会总是很幸运地写出你所有的代码。

NOTE: Don't focus too much on efficiency issues until you actually learn a little about how compilers work. With a little experience coding you don't have to learn that much about them before you realize how much they are able to generalize good code into something something simple. Every bit as simple as if you wrote the whole thing in C. Good code is only as complex as it needs to be.

注意:在您真正了解编译器如何工作之前，不要太关注效率问题。有了一点经验编码，你就不必在你意识到他们能把好的代码推广到一些简单的东西之前了解它们。每一点都很简单，就像你把整个事情写在c里一样，好的代码也只是像它需要的那样复杂。

#26

I agree with others - it is asking for name *es, ambiguities and then the fact is it is less explicit. While I can see the use of using ... my personal preference is to limit it. I would also strongly consider what some others pointed out:

我同意其他人的观点——它要求名称冲突，含糊不清，但事实是它不那么明确。虽然我可以看到使用…我个人的偏好是限制它。我还会强烈地考虑其他一些人指出的:

If you want to find a function name that might be a fairly common name, but you only want to find it in std namespace (or the reverse: you want to change all calls that are NOT in namespace std, namespace X, ...), then how do you propose to do this? You could write a program to do it but wouldn't it be better to spend time working on your project itself rather than writing a program to maintain your project?

如果你想找到一个函数名可能是一个相当普通的名字,但你只想找到它在std名称空间(或相反的:你想改变没有名称空间的所有调用std,名称空间X,…),那你怎么打算呢?您可以编写一个程序来完成它，但是花时间在您的项目本身上，而不是编写一个程序来维护您的项目不是更好吗?

Personally I actually don't mind the std:: prefix. I like the look more than not. I don't know if that is because it is explicit and says to me "this isn't my code... I am using the standard library" or if it is something else, but I think it looks nicer. This might be odd given that I only recently got in to C++ (used and still do C and other languages for much longer and C is my favourite language of all time, right above assembly).

我个人并不介意std::前缀。我更喜欢它的外观。我不知道这是不是因为它很明确地告诉我“这不是我的代码……”我使用的是标准库，或者它是别的东西，但我觉得它看起来更好。这可能有点奇怪，因为我最近才进入c++(使用和仍然使用C语言和其他语言的时间更长，C是我一直以来最喜欢的语言，就在程序集之上)。

There is one other thing although it is somewhat related to the above and what others point out. While this might be bad practise, I sometimes reserve std::name for standard library version and name for program-specific implementation. Yes indeed this could bite you and bite you hard but it all comes down to that I started this project from scratch and I'm the only programmer for it. Example: I overload std::string and call it string. I have helpful additions. I did it in part because of my C and Unix (+ Linux) tendency towards lower-case names.

还有一件事，尽管它与上面的和别人指出的有点关系。虽然这可能是糟糕的实践，但我有时会保留std::标准库版本的名称和特定于程序的实现的名称。是的，这可能会咬你，咬你，但这一切都归结到我从头开始这个项目，我是唯一的程序员。示例:我重载std::string并调用它字符串。我有有益的补充。我之所以这么做，部分是因为我的C和Unix (+ Linux)倾向于小写的名称。

Besides that, you can have namespace aliases. Here is an example of where it is useful that might not have been referred to (I didn't read all the responses and I'm having to rush off for a while in a moment). I use the C++11 standard and specifically with libstdc++. Well check this. It doesn't have complete std::regex support. Sure it compiles but it throws an exception along the lines of it being an error on the programmer's end. But it is lack of implementation. So here's how I solved it. Install boost's regex, link in boost's regex. Then, I do the following so that when libstdc++ has it implemented entirely, I need only remove this block and the code remains the same:

除此之外，您还可以使用名称空间别名。这里有一个例子，说明它在哪里是有用的，可能没有提到(我没有读到所有的回复，我必须马上离开一会儿)。我使用c++ 11标准，特别是libstdc++。检查这个。它没有完整的std::regex支持。当然，它会编译，但它会抛出一个异常，这是程序员的一个错误。但它缺乏实施。这就是我的解。安装boost的regex，链接到boost的regex。然后，我执行以下操作，以便当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;  
}

I won't argue on whether that is a bad idea or not. I will however argue that it keeps it clean for MY project and at the same time makes it specific: True I have to use boost BUT I'm using it like the libstdc++ will eventually have it. Yes, starting your own project and starting with a standard (...) at the very beginning goes a very long way with helping maintenance, development and everything involved with the project!

我不会争论那是不是一个坏主意。但是，我认为它可以为我的项目保持它的清洁，同时也使它变得更具体:我必须使用boost，但我使用它就像libstdc++最终拥有它一样。是的，开始你自己的项目，并从一个标准开始(…)，在开始的时候，帮助维护，开发和项目的所有事情都有很长的一段路要走!

Edit: Now that I have time, just to clarify something. I don't actually think it is a good idea to use a name of a class/whatever in the STL deliberately and more specifically in place of. string is the exception (ignore the first, above, or second here, pun if you must) for me as I didn't like the idea of 'String'. As it is, I am still very biased towards C and biased against C++. Sparing details, much of what I work on fits C more (but it was a good exercise and a good way to make myself a. learn another language and b. try not be less biased against object/classes/etc which is maybe better stated as: less closed-minded, less arrogant, more accepting.). But what IS useful is what some already suggested: I do indeed use list (it is fairly generic, is it not ?), sort (same thing) to name two that would cause a name * if I were to do "using namespace std;" and so to that end I prefer being specific, in control and knowing that if I intend it to be the standard use then I will have to specify it. Put simply: no assuming allowed.

现在我有时间了，只是想澄清一些事情。我实际上并不认为在STL中使用一个类的名称是一个好主意，更确切地说，它是用来代替的。字符串是例外(忽略第一个，上面，或者第二个，如果你必须)，因为我不喜欢“字符串”的概念。尽管如此，我仍然偏向于C，对c++有偏见。我做的大部分工作都比较适合(但这是一种很好的锻炼，也是让我自己学习的好方法)。但什么是有用的是一些已经建议:我确实使用列表(这是相当普通的,不是吗?),(同一件事)名称排序两个会导致一个名字冲突如果我做“使用名称空间性病;”,所以为此我喜欢具体,在控制和知道如果我打算标准使用然后我必须指定它。简单地说:不允许。

And as for making boost's regex part of std. I do that for future integration and - again, I admit fully this is bias - I don't think it is as ugly as boost::regex:: ... Indeed that is another thing for me. There's many things in C++ that I still have yet to come to fully accept in looks and methods (another example: variadic templates versus var args [though I admit variadic templates are very very useful!]). Even those that I do accept it was difficult AND I still have issues with them.

至于提高std的regex部分，我是为了以后的整合而做的，而且，我完全承认这是偏见——我不认为它像boost::regex::……事实上，这对我来说是另一回事。在c++中有很多东西，我还没有完全接受外观和方法(另一个例子:可变模板和var args[尽管我承认可变模板非常有用!])。即使是那些我接受的也很困难，我仍然有问题。

#27

It depends on where it is located. If it is a common header, then you are diminishing the value of the namespace by merging it into the global namespace. Keep in mind, this could be a neat way of making module globals.

这取决于它的位置。如果它是一个公共标头，那么您将通过将其合并到全局名称空间中来减少名称空间的值。请记住，这可能是制作模块全局的一种简洁的方式。

#28

From my experiences, if you have multiple libraries that uses say, cout, but for a different purpose you may use the wrong cout.

从我的经验来看，如果你有多个库，使用的是cout，但是为了不同的目的，你可能会使用错误的cout。

For example, if I type in, using namespace std; and using namespace otherlib; and type just cout (which happens to be in both), rather than std::cout (or 'otherlib::cout'), you might use the wrong one, and get errors, it's much more effective and efficient to use std::cout.

例如，如果我输入，使用名称空间std;和使用名称空间otherlib;而type just cout(恰好在两者中)，而不是std::cout(或“otherlib: cout”)，您可能会使用错误的一个，并得到错误，使用std::cout更加有效和高效。

#29

This is a bad practice, often known as global namespace pollution. Problems may occur when more than one namespace has the same function name with signature, then it will be ambiguous for the compiler to decide which one to call and this all can be avoided when you are specifying the namespace with your function call like std::cout . Hope this helps. :)

这是一个糟糕的实践，通常被称为全局名称空间污染。当多个名称空间具有与签名相同的函数名时，可能会出现问题，然后编译器将会模糊地决定要调用哪个函数，而当您使用函数调用(如std::cout)指定名称空间时，这一切都可以避免。希望这个有帮助。:)

#30

I think using locally or globally should depend on the application.

我认为在本地或全球使用应该依赖于应用程序。

Because, when we use the library locally, sometimes code going to be a real mess. Readability is going to low.

因为，当我们在本地使用库时，有时代码会变得非常混乱。可读性很低。

so, we should use libraries locally when only there is a possibility for conflicts.

因此，我们应该在只有存在冲突可能性的情况下使用本地库。

I am not more experiences person. So, let me know if I am wrong.

我不是更有经验的人。所以，如果我错了，请告诉我。