根据我的经验，如果你有多个库使用cout，但出于不同的目的，你可能会使用错误的cout。

例如，如果我键入，使用名称空间std；并使用命名空间otherlib；如果只键入cout（恰好两者都有），而不是std:：cout（或'otherlib:：cout'），则可能会使用错误的一个，并出现错误。使用std:：cout更有效。

这可能比Greg写的更糟！

Library Foo 2.0可能会引入一个函数Qux（），它无疑比多年来代码调用的bar:：Qux）更适合您对Qux的某些调用。然后你的代码仍然可以编译，但它会默默地调用错误的函数，上帝知道会发生什么。这是最糟糕的事情了。

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

如果你认为这不太可能：在我给出这个答案大约半年后，在Stack Overflow上有一个问题（由于省略了std:：前缀而调用了错误的函数）。这是这一问题的另一个最近的例子。所以这是一个真正的问题。

这里还有一个数据点：很多很多年前，我还发现必须在标准库中的所有内容前面加上std:：，这很烦人。然后我在一个项目中工作，一开始就决定禁止使用指令和声明，但函数作用域除外。猜猜怎么了？我们中的大多数人花了几周的时间才习惯写前缀，再过几周，我们中的大部分人甚至同意这实际上使代码更可读。这是有原因的：你喜欢较短或较长的散文是主观的，但前缀客观上增加了代码的清晰度。不仅是编译器，您也会发现更容易看到引用的是哪个标识符。

在十年内，该项目发展到拥有数百万行代码。由于这些讨论一次又一次出现，我一度很好奇项目中实际使用（允许）函数范围的频率。我查阅了它的来源，只找到了一两打使用它的地方。对我来说，这表明，一旦尝试过，即使在允许使用std:：的地方，开发人员也不会觉得每100kLoC使用一次指令就足够痛苦。

一句话：明确地给每件事加上前缀不会造成任何伤害，只需要很少的时间就可以习惯，而且有客观的优势。特别是，它使编译器和人类读者更容易解释代码，这可能是编写代码时的主要目标。

如果您导入了右侧的头文件，您的全局范围中会突然出现十六进制、左侧、加号或count等名称。如果您不知道std:：包含这些名称，这可能会令人惊讶。如果您也尝试在本地使用这些名称，可能会导致一些混淆。

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

为什么使用命名空间标准？

C++有一个标准库，其中包含构建应用程序时使用的常用功能，如容器、算法等。如果这些库使用的名称是公开的，例如，如果它们全局定义了一个队列类，那么您将无法再次使用相同的名称而不发生冲突。因此，他们创建了一个名称空间std来包含此更改。

不使用的原因1：不良行为

使用命名空间std的语句通常被认为是错误的做法。此语句的另一种方法是在每次声明类型时使用作用域运算符（：：）指定标识符所属的命名空间。尽管该语句避免了我们在任何时候希望访问std命名空间中定义的类或类型时键入std:：，但它将整个std命名空间导入到程序的当前命名空间中。

不使用的原因2：编译器变得混乱

在玩具程序中导入整个std库是可以的，但在生产级代码中，这是不好的。使用命名空间std；使命名空间std中声明的每个符号都可以在没有命名空间限定符的情况下访问。

例如：

现在，假设您升级到一个较新版本的C++，并将更多新的std命名空间符号注入到您不知道的程序中。您的程序中可能已经使用了这些符号。现在编译器将很难弄清楚声明的符号是属于您自己的实现，还是来自您在没有任何概念的情况下导入的名称空间。一些编译器会抛出错误。如果运气不好，编译器选择了错误的实现并编译它，这肯定会导致运行时崩溃。

命名空间污染影响：

虽然这种做法对于示例代码来说是可以的，但将整个std命名空间拉入全局命名空间是不好的，因为它会破坏命名空间的目的，并可能导致名称冲突。这种情况称为命名空间污染。

一个具体的例子来澄清这个问题。假设您有两个库，foo和bar，每个库都有自己的名称空间：

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

namespace bar {
    ...
}

现在假设您在自己的程序中同时使用foo和bar，如下所示：

using namespace foo;
using namespace bar;

void main() {
    a(42);
}

现在一切都很好。当你运行程序时，它会“做一些事情”。但后来你更新了这个栏，让我们假设它变成了这样：

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:：）。

但想象一下另一种情况，酒吧改成了这样：

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

此时，您对a（42）的调用突然绑定到bar:：a而不是foo:：a，并且它不做“某事”，而是做“完全不同的事情”。没有编译器警告或任何内容。你的程序只是默默地开始做一些与以前完全不同的事情。

当你使用一个名称空间时，你会面临这样的风险，这就是为什么人们不喜欢使用名称空间的原因。名称空间中的东西越多，冲突的风险就越大，因此与其他名称空间相比，人们可能更不喜欢使用名称空间std（由于该名称空间中有很多东西）。

最终，这是可写性与可靠性/可维护性之间的权衡。可读性也可能是其中的一个因素，但无论哪种方式，我都能看到这样做的理由。通常，我会说可靠性和可维护性更重要，但在这种情况下，您将不断为相当罕见的可靠性/可维护性影响支付可写性成本。“最佳”权衡将决定您的项目和优先级。

命名空间是命名作用域。命名空间用于对相关声明进行分组并保持独立项目分开。例如，两个单独开发的库可以使用相同的名称来表示不同的项，但用户仍然可以同时使用这两个：

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

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

来源：C++编程语言概述作者：Bjarne Stroustrup