C++ 使用 std 命名空间

Using std Namespace

提问by paoloricardo

There seem to be different views on using 'using' with respect to the std namespace.

关于 std 命名空间使用“使用”似乎有不同的看法。

Some say use ' using namespace std', other say don't but rather prefix std functions that are to be used with ' std::' whilst others say use something like this:

有人说使用 ' using namespace std'，有人说不要，而是使用前缀 std 函数与 ' std::'一起使用，而其他人说使用类似这样的东西：

using std::string;
using std::cout;
using std::cin;
using std::endl;
using std::vector;

for all the std functions that are to be used.

对于所有要使用的 std 函数。

What are the pros and cons of each?

各自的优缺点是什么？

回答by CB Bailey

Most C++ users are quite happy reading std::string, std::vector, etc. In fact, seeing a raw vectormakes me wonder if this is the std::vectoror a different user-defined vector.

大多数 C++ 用户都非常喜欢阅读std::string、std::vector等。事实上，看到原始文件vector让我怀疑这是std::vector用户定义的还是不同的vector.

I am always against using using namespace std;. It imports all sorts of names into the global namespace and can cause all sorts of non-obvious ambiguities.

我总是反对使用using namespace std;. 它将各种名称导入全局命名空间，并可能导致各种不明显的歧义。

Here are some common identifiers that are in the stdnamespace: count, sort, find, equal, reverse. Having a local variable called countmeans that using namespace stdwon't enable you to use countinstead of std::count.

以下是std命名空间中的一些常见标识符：count、sort、find、equal、reverse。有一个局部变量被称为count意味着using namespace std不会让你使用count代替std::count.

The classic example of an unwanted name conflict is something like the following. Imagine that you are a beginner and don't know about std::count. Imagine that you are either using something else in <algorithm>or it's been pulled in by a seemingly unrelated header.

不需要的名称冲突的经典示例如下所示。假设您是初学者并且不了解std::count. 想象一下，你要么在使用其他东西，<algorithm>要么被一个看似无关的标题拉进来。

#include <algorithm>
using namespace std;

int count = 0;

int increment()
{
    return ++count; // error, identifier count is ambiguous
}

The error is typically long and unfriendly because std::countis a template with some long nested types.

该错误通常很长且不友好，因为std::count它是具有一些长嵌套类型的模板。

This is OK though, because std::countgoes into the global namespace and the function count hides it.

不过这没关系，因为std::count进入全局命名空间并且函数 count 隐藏了它。

#include <algorithm>
using namespace std;

int increment()
{
    static int count = 0;
    return ++count;
}

Perhaps slightly surprisingly, this is OK. Identifiers imported into a declarative scope appear in the common namespace that encloses both where they are defined and where they are imported into. In other words, std::countis visible as countin the global namespace, but only inside increment.

也许有点令人惊讶，这是可以的。导入声明性作用域的标识符出现在包含定义它们的位置和导入它们的位置的公共命名空间中。换句话说，在全局命名空间中std::count是可见的count，但只能在increment.

#include <algorithm>

int increment()
{
    using namespace std;
    static int count = 0;
    return ++count;
}

And for similar reasons, countis ambiguous here. using namespace stddoesn't cause std::count, hide the outer countas it might be expected. The using namespacerule means that std::countlooks (in the incrementfunction) as though it was declared at the global scope, i.e. at the same scope as int count = 0;and hence causing the ambiguity.

出于类似的原因，count这里是模棱两可的。using namespace std不会导致std::count，count按照预期隐藏外部。该using namespace规则意味着std::count看起来（在increment函数中）好像它是在全局范围内声明的，即在相同的范围内int count = 0;并因此导致歧义。

#include <algorithm>

int count = 0;

int increment()
{
    using namespace std;
    return ++count; // error ambiguous
}

回答by Yacoby

Excluding the basics (Having to add std:: infront of all stl objects/functions and less chance of conflict if you don't have 'using namespace std')

排除基础知识（必须在所有 stl 对象/函数的前面添加 std:: 并且如果您没有“使用命名空间 std”，则冲突的可能性较小）

It is also worth noting that you should never put

还值得注意的是，你永远不应该把

using namespace std

In a header file, as it can propagate to all files that include that header file, even if they don't want to use that namespace.

在头文件中，因为它可以传播到包含该头文件的所有文件，即使它们不想使用该命名空间。

In some cases it is very beneficial to use things like

在某些情况下，使用诸如

using std::swap

As if there is a specialized version of swap, the compiler will use that, otherwise it will fall back on std::swap.

好像有一个专门的 swap 版本，编译器会使用它，否则它会回退到std::swap.

If you call std::swap, you always use the basic version, which will not call the optimized version (if it exists).

如果调用std::swap，则始终使用基本版本，不会调用优化版本（如果存在）。

回答by Michael Burr

First, some terminology:

首先，一些术语：

• using-declaration: using std::vector;
• using-directive: using namespace std;

• 使用声明： using std::vector;
• 使用指令： using namespace std;

I think that using using-directivesare fine, as long as they aren't used at the global scope in a header file. So having

我认为使用using-directives很好，只要它们不在头文件的全局范围内使用。所以有

using namespace std;

in your .cpp file isn't really a problem, and if it turns out to be, it's completely under your control (and it can even be scoped to particular blocks if desired). I see no particlar reason to clutter up the code with a slew of std::qualifiers - it just becomes a bunch of visual noise. However, if you're not using a whole bunch of names from the stdnamespace in your code, I also see no problem with leaving out the directive. It's a tautology - if the directive isn't necessary, then there's no need to use it.

在您的 .cpp 文件中并不是一个真正的问题，如果事实证明是这样，它完全在您的控制之下（如果需要，它甚至可以限定为特定块）。我看不出有什么特别的理由用一系列std::限定符来弄乱代码——它只是变成了一堆视觉噪音。但是，如果您没有std在代码中使用命名空间中的一大堆名称，我也认为省略该指令没有问题。这是一个同义反复——如果指令不是必需的，那么就没有必要使用它。

Similarly, if you can get by with a few using-declarations(instead of using-directives) for specfic types in the stdnamespace, then there's no reason you shouldn't have just those spefcific names brought into the current namespace. By the same token, I think it would be crazy and a bookkeeping hassle to have 25 or 30 using-declarations when a single using-directive would do the trick just as well.

类似地，如果您可以为命名空间中的特定类型使用一些using 声明（而不是using-directives）std，那么您没有理由不将那些特定名称引入当前命名空间。出于同样的原因，我认为当单个 using 指令也能做到这一点时，拥有 25 或 30 个 using 声明将是疯狂和记账的麻烦。

It's also good to keep in mind that there are times when you mustuse a using-declaration. Refer to Scott Meyers' "Item 25: Consider support for a non-throwing swap" from Effective C++, Third Edition. In order to have a generic, templated function use the 'best' swap method for a parameterized type, you need to make use of a using-declaration and argument dependant lookup (aka ADL or Koenig lookup):

记住有时您必须使用 using 声明也很好。请参阅《Effective C++》第三版中 Scott Meyers 的“条款 25：考虑支持非抛出交换”。为了让通用的模板化函数对参数化类型使用“最佳”交换方法，您需要使用 using 声明和参数相关查找（又名 ADL 或 Koenig 查找）：

template< typename T >
void foo( T& x, T& y)
{
    using std::swap;     // makes std::swap available in this function

    // do stuff...

    swap( x, y);         // will use a T-specific swap() if it exists,
                         //  otherwise will use std::swap<T>()

    // ...
 }

I think we should look at the common idioms for various languages that make significant use of namespaces. For example, Java and C# use namespaces to a large extent (arguably moreso than C++). The most common way names within namespaces are used in those languages is by bringing them into the current scope en masse with the equivalent of a using-directive. This doesn't cause wide-spread problems, and the few times it is a problem are handled on an 'exception' basis by dealing with the names in question via fully-qualified names or by aliasing - just like can be done in C++.

我认为我们应该看看大量使用命名空间的各种语言的常见习语。例如，Java 和 C# 在很大程度上使用命名空间（可以说比 C++ 更）。在这些语言中，命名空间中的名称最常见的使用方式是将它们与 using 指令的等效项一起引入当前范围。这不会导致广泛存在的问题，并且通过完全限定名称或别名处理有问题的名称，在“异常”基础上处理少数问题 - 就像可以在 C++ 中完成的一样。

Herb Sutter and Andrei Alexandrescu have this to say in "Item 59: Don't write namespace usings in a header file or before an #include" of their book, C++ Coding Standards: 101 Rules, Guidelines, and Best Practices:

Herb Sutter 和 Andrei Alexandrescu 在他们的《C++ 编码标准：101 条规则、指南和最佳实践》一书中的“第 59 条：不要在头文件中或#include 之前编写命名空间使用”中说：

In short: You can and should use namespace using declarations and directives liberally in your implementation files after #includedirectives 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.

简而言之：您可以并且应该在#include指令之后的实现文件中自由地使用命名空间 using 声明和指令，并且对此感觉良好。尽管一再有相反的断言，使用命名空间的声明和指令并不是邪恶的，它们不会违背命名空间的目的。相反，它们使命名空间可用。

Stroupstrup is often quoted as saying, "Don't pollute the global namespace", in "The C++ Programming Language, Third Edition". He does in fact say that (C.14[15]), but refers to chapter C.10.1 where he says:

在“The C++ Programming Language, Third Edition”中，Strupstrup 经常被引用说“不要污染全局命名空间”。事实上，他确实这么说 (C.14[15])，但他提到了 C.10.1 章，他说：

A using-declarationadds a name to a local scope. A using-directivedoes not; it simply renders names accessible in the scope in which they were declared. For example:

namespaceX {
    int i , j , k ;
}

int k ;
void f1()
{
    int i = 0 ;

    using namespaceX ; // make names from X accessible

    i++; // local i
    j++; // X::j
    k++; // error: X::k or global k ?

    ::k ++; // the global k

    X::k ++; // X's k
}

void f2()
{
    int i = 0 ;

    using X::i ; // error: i declared twice in f2()
    using X::j ;
    using X::k ; // hides global k

    i++;
    j++; // X::j
    k++; // X::k
}

A locally declared name (declared either by an ordinary declaration or by a using-declaration) hides nonlocal declarations of the same name, and any illegal overloadings of the name are detected at the point of declaration.

Note the ambiguity error for k++in f1(). Global names are not given preference over names from namespaces made accessible in the global scope. This provides significant protection against accidental name clashes, and – importantly – ensures that there are no advantages to be gained from polluting the global namespace.

When libraries declaring many names are made accessible through using-directives, it is a significant advantage that clashes of unused names are not considered errors.

...

I hope to see a radical decrease in the use of global names in new programs using namespaces compared to traditional C and C++ programs. The rules for namespaces were specifically crafted to give no advantages to a ‘‘lazy'' user of global names over someone who takes care not to pollute the global scope.

一个using声明增加了一个名字，以局部范围。一个using指令没有; 它只是使名称在声明它们的范围内可访问。例如：

namespaceX {
    int i , j , k ;
}

int k ;
void f1()
{
    int i = 0 ;

    using namespaceX ; // make names from X accessible

    i++; // local i
    j++; // X::j
    k++; // error: X::k or global k ?

    ::k ++; // the global k

    X::k ++; // X's k
}

void f2()
{
    int i = 0 ;

    using X::i ; // error: i declared twice in f2()
    using X::j ;
    using X::k ; // hides global k

    i++;
    j++; // X::j
    k++; // X::k
}

本地声明的名称（由普通声明或 using 声明声明）隐藏了同名的非本地声明，并且在声明点检测到名称的任何非法重载。

注意k++in 的歧义错误f1()。全局名称不会优先于在全局范围内可访问的命名空间中的名称。这为防止意外名称冲突提供了重要的保护，而且——重要的是——确保不会从污染全局命名空间中获得任何好处。

当声明许多名称的库可以通过 using 指令访问时，一个显着的优势是未使用名称的冲突不会被视为错误。

...

与传统的 C 和 C++ 程序相比，我希望在使用命名空间的新程序中看到全局名称的使用急剧减少。命名空间的规则是专门为全局名称的“懒惰”用户而设计的，而不是给那些注意不污染全局范围的人带来任何好处。

And how does one have the same advantage as a 'lazy user of global names'? By taking advantage of the using-directive, which safelymakes names in a namespace available to the current scope.

一个人如何拥有与“全球名称的懒惰用户”相同的优势？通过利用 using 指令，它可以安全地使命名空间中的名称对当前作用域可用。

Note that there's a distinction - names in the stdnamespace made available to a scope with the proper use of a using-directive (by placing the directive after the #includes) does notpollute the global namespace. It's just making those names available easily, and with continued protection against clashes.

请注意，有一个区别 -std命名空间中的名称通过正确使用 using 指令（通过将指令放置在 之后#includes）提供给作用域不会污染全局命名空间。它只是使这些名称易于使用，并持续防止冲突。

回答by AProgrammer

Never use using namespace at global scope in an header file. That can leads to conflict and the person in charge of the file where the conflict appears has no control on the cause.

切勿在头文件中的全局范围内使用 using 命名空间。这可能会导致冲突，并且出现冲突的文件的负责人无法控制原因。

In implementation file, the choices are far less well cut.

在实现文件中，选择要少得多。

• Putting a using namespace std brings all the symbols from that namespaces. This can be troublesome as nearly no body know all the symbols which are there (so having a policy of no conflict is impossible to apply in practice) without speaking of the symbols which will be added. And the C++ standard allows an header to add symbols from other headers (the C one doesn't allow that). It still can work well in practice to simplify the writing in controlled case. And if an error occur, it is detected in the file which has the problem.

• Putting using std::name; has the advantage of simplicity of writing without the risk of importing unknown symbols. The cost is that you have to import explicitly all wanted symbols.

• Explicitly qualifying add a little clutter, but I think it is the less trouble some practice.

• 放置一个 using 命名空间 std 会带来该命名空间中的所有符号。这可能会很麻烦，因为几乎没有人知道存在的所有符号（因此在实践中不可能应用不冲突的政策）而不涉及将添加的符号。并且 C++ 标准允许头文件添加来自其他头文件的符号（C 标准不允许这样做）。它在实践中仍然可以很好地简化受控情况下的编写。如果发生错误，则会在有问题的文件中检测到错误。

• 使用 std::name 放置；具有书写简单的优点，没有导入未知符号的风险。代价是您必须明确导入所有想要的符号。

• 明确的排位赛增加了一些混乱，但我认为这是一些练习的麻烦。

In my project, I use explicit qualification for all names, I accept using std::name, I fight against using namespace std (we have an lisp interpreter which has his own list type and so conflict is a sure thing).

在我的项目中，我对所有名称使用显式限定，我接受使用 std::name，我反对使用命名空间 std（我们有一个 lisp 解释器，它有自己的列表类型，因此冲突是肯定的）。

For other namespaces, you have also to take into account the naming conventions used. I know of a project which use namespace (for versionning) and prefix on names. Doing a using namespace Xthen is nearly without risk and not doing it leads to stupid looking code PrefixNS::pfxMyFunction(...).

对于其他命名空间，您还必须考虑使用的命名约定。我知道一个使用命名空间（用于版本控制）和名称前缀的项目。做using namespace Xthen 几乎没有风险，不做会导致代码看起来很愚蠢PrefixNS::pfxMyFunction(...)。

There are some cases where you want to import the symbols. std::swap is the most common case: you import std::swap and then use swap unqualified. Argument dependent lookup will find an adequate swap in the namespace of the type if there is one and fall back to the standard template if there is none.

在某些情况下，您要导入符号。std::swap 是最常见的情况：您导入 std::swap 然后使用不合格的交换。参数相关查找将在类型的命名空间中找到足够的交换（如果有），如果没有，则回退到标准模板。

---

---

Edit:

编辑：

In the comments, Michael Burr wonders if the conflicts occur in real world. Here is a real live exemple. We have an extension language with is a lisp dialect. Our interpreter has an include file, lisp.h containing

在评论中，迈克尔·伯尔想知道冲突是否发生在现实世界中。这是一个真实的例子。我们有一种带有 lisp 方言的扩展语言。我们的解释器有一个包含文件 lisp.h

typedef struct list {} list;

We had to integrate and adapt some code (which I'll name "engine") which looked like this:

我们必须集成和调整一些代码（我将其命名为“引擎”），如下所示：

#include <list>
...
using std::list;
...
void foo(list const&) {}

So we modified like this:

所以我们修改如下：

#include <list>

#include "module.h"
...
using std::list;
...
void foo(list const&) {}

Good. Everything work. Some months later, "module.h" was modified to include "list.h". The tests passed. "module" hadn't be modified in a way that affected its ABI, so "engine" library could be used without re-compiling its users. Integration tests were OK. New "module" published. Next compilation of engine broke when its code hasn't be modified.

好的。一切正常。几个月后，“module.h”被修改为包含“list.h”。测试通过了。“模块”没有以影响其 ABI 的方式进行修改，因此可以使用“引擎”库而无需重新编译其用户。集成测试没问题。发布了新的“模块”。当引擎的代码没有被修改时，引擎的下一次编译就中断了。

回答by Tadeusz Kopec

Both

两个都

using std::string;

and

和

using namespace std;

add some symbols (one or lots of) to the global namespace. And adding symbols to global namespace is something you should neverdo in header files. You have no control who will include your header, there are lots of headers that include other headers (and headers that include headers that include headers and so on...).

向全局命名空间添加一些符号（一个或多个）。向全局命名空间添加符号是你永远不应该在头文件中做的事情。您无法控制谁将包含您的标头，有很多标头包含其他标头（以及包含标头的标头，等等...）。

In implementation (.cpp) files it's up to you (only remember to do it afterall #include directives). You can break only code in this specific file, so it's easier to manage and find out the reason of name conflict. If you prefer to use std:: (or any other prefix, there can be many namespaces in your project) before indentifiers, it's OK. If you like to add identifiers you use to global namespace, it's OK. If you want to bring whole namespace on your head :-), it's up to you. While the effects are limited to single compilation unit, it's acceptable.

在实现 (.cpp) 文件中，这取决于您（只记得在所有 #include 指令之后执行此操作）。您只能破解该特定文件中的代码，因此更易于管理和查找名称冲突的原因。如果您更喜欢在标识符之前使用 std::（或任何其他前缀，您的项目中可以有许多命名空间），也可以。如果您想将您使用的标识符添加到全局命名空间，那也没关系。如果你想把整个命名空间放在你的头上:-)，这取决于你。虽然影响仅限于单个编译单元，但它是可以接受的。

回答by Matthieu

If you don't have a risk of name conflicts in your code with std and other libraries you can use :

如果您的代码中没有与 std 和其他库发生名称冲突的风险，则可以使用：

using namespace std;

But if you want know precisely the dependancy of your code for documentation or there is a risk of name conflicts use the other way :

但是，如果您想准确了解文档代码的依赖性，或者存在名称冲突的风险，请使用另一种方式：

using std::string;
using std::cout;

The third solution, don't use these solutions and write std:: before each use in code brings you more security but, maybe a little heaviness in the code...

第三种解决方案，不要使用这些解决方案并在每次使用代码之前编写 std:: 为您带来更多安全性，但是，代码中可能有点沉重......

回答by AraK

For me, I prefer to use ::when possible.

对我来说，我更喜欢::在可能的情况下使用。

std::list<int> iList;

I hate to write :

我讨厌写：

for(std::list<int>::iterator i = iList.begin(); i != iList.end(); i++)
{
    //
}

Hopefully, with C++0x I would write this:

希望使用 C++0x 我会这样写：

for(auto i = iList.begin(); i != iList.end(); i++)
{
    //
}

If the namespace is very lengthy,

如果命名空间很长，

namespace dir = boost::filesystem;

dir::directory_iterator file("e:/boost");
dir::directory_iterator end;

for( ; file != end; file++)
{
    if(dir::is_directory(*file))
        std::cout << *file << std::endl;
}

回答by sbi

You should never be using namespace stdat namespace scope in a header. Also, I suppose most programmers will wonder when they see vectoror stringwithout std::, so I think not using namespace stdis better. Therefor I argue for never be using namespace stdat all.

您永远不应该using namespace std处于标题中的命名空间范围内。另外，我想大多数程序员会想知道他们什么时候看到vector或string没有std::，所以我认为不是using namespace std更好。因此，我主张永远不存在using namespace std。

If you feel like you must, add local using declarations like using std::vector. But ask yourself: What's this worth? A line of code is written once (maybe twice), but it's read ten, hundred or thousand times. The saved typing effort be adding a using declaration or directive is marginal compared to the effort of reading the code.

如果您觉得必须，请添加 local using 声明，例如using std::vector. 但问问自己：这有什么价值？一行代码只写了一次（也许两次），但它被阅读了十次、一百次或一千次。与阅读代码的工作相比，添加 using 声明或指令所节省的打字工作是微不足道的。

With that in mind, in a project ten years ago we decided to explicitly qualify all identifiers with their full namespace names. What seemed awkward at first became routine within two weeks. Now, in all projects of that whole company nobody is using using directives or declarations anymore. (With one exception, see below.) Looking at the code (several MLoC) after ten years, I feel like we made the right decision.

考虑到这一点，在十年前的一个项目中，我们决定使用完整的命名空间名称明确限定所有标识符。起初看起来很尴尬的事情在两周内变成了例行公事。现在，在整个公司的所有项目中，没有人再使用 using 指令或声明了。（有一个例外，见下文。）十年后查看代码（几个 MLoC），我觉得我们做出了正确的决定。

I've found that usually, those who oppose banning usingusually haven't tried it for one project. Those who have tried, often find it better than using directives/declarations after a very short time.

我发现通常，那些反对禁止的人using通常没有为一个项目尝试过。那些尝试过的人通常会在很短的时间内发现它比使用指令/声明更好。

Note: The only exception is using std::swapwhich is necessary (especially in generic code) to pick up overloads of swap()that cannot be put into the stdnamespace (because we aren't allowed to put put overloads of stdfunctions into this namespace).

注意：唯一的例外是using std::swap需要（特别是在通用代码中）拾取swap()不能放入std命名空间的重载（因为我们不允许将std函数的重载放入这个命名空间）。

回答by Cees Timmerman

Namespaces keep code contained to prevent confusionand pollutionof function signatures.

命名空间保持包含代码以防止函数签名的混淆和污染。

Here's a complete and documented demo of propernamespaceusage:

这是正确命名空间使用的完整和文档化演示：

#include <iostream>
#include <cmath>  // Uses ::log, which would be the log() here if it were not in a namespace, see https://stackoverflow.com/questions/11892976/why-is-my-log-in-the-std-namespace

// Silently overrides std::log
//double log(double d) { return 420; }

namespace uniquename {
    using namespace std;  // So we don't have to waste space on std:: when not needed.

    double log(double d) {
        return 42;
    }

    int main() {
        cout << "Our log: " << log(4.2) << endl;
        cout << "Standard log: " << std::log(4.2);
        return 0;
    }
}

// Global wrapper for our contained code.
int main() {
    return uniquename::main();
}

Output:

输出：

Our log: 42
Standard log: 1.43508

回答by Wookai

using namespace stdimports the content of the stdnamespace in the current one. Thus, the advantage is that you won't have to type std::in front of all functions of that namespace. However, it may happen that you have different namespaces that have functions of the same name. Thus, you may end not calling the one you want.

using namespace std导入std当前命名空间的内容。因此，优点是您不必std::在该命名空间的所有函数前面键入。但是，可能会发生具有相同名称函数的不同名称空间。因此，您可能最终不会拨打您想要的电话。

Specifying manually which ones you want to import in stdprevents that from happening, but may result in a long list of using at the beginning of your file, which some developer will find ugly ;) !

手动指定要导入的内容std可以防止这种情况发生，但可能会导致在文件开头使用很长的列表，有些开发人员会发现这很难看 ;) ！

Personally, I prefer specifying the namespace each time I use use a function, except when the namespace is too long, in which case I put some using at the beginning of the file.

就我个人而言，我更喜欢在每次使用 use 函数时指定命名空间，除非命名空间太长，在这种情况下，我会在文件的开头放一些 using。

EDIT: as noted in another answer, you should never put a using namespacein a header file, as it will propagage to all files including this header and thus may produce unwanted behavior.

编辑：如另一个答案中所述，您永远不应该将 ausing namespace放入头文件中，因为它会传播到包括此头的所有文件，因此可能会产生不需要的行为。

EDIT2: corrected my answer, thanks to Charles comment.

EDIT2：更正我的答案，感谢查尔斯的评论。