一个具体的例子来澄清这个问题。假设您有两个库，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（由于该名称空间中有很多东西）。

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

您需要能够阅读与您不同风格和最佳实践意见的人编写的代码。如果你只使用cout，没有人会感到困惑。但是，当你有很多名称空间到处飞的时候，你看到这个类，你不太确定它做什么时，让名称空间显式充当某种注释。您可以第一眼看到，“哦，这是一个文件系统操作”或“这是在做网络工作”。

短版本：不要在头文件中使用全局using声明或指令。可以在实现文件中使用它们。以下是Herb Sutter和Andrei Alexandrescu在C++编码标准中对这个问题的看法（我用粗体强调）：

总结命名空间using是为了方便您，而不是为了强加给他人：不要在#include指令之前编写using声明或using指令。推论：在头文件中，不要使用指令或声明编写命名空间级别；相反，显式命名空间限定所有名称。（第二条规则与第一条规则相同，因为标头永远无法知道后面可能出现的其他标头#includes。）讨论简而言之：在#include指令之后，你可以也应该在你的实现文件中自由地使用命名空间使用声明和指令，并对此感到满意。尽管重复了相反的断言，但使用命名空间的声明和指令并不是邪恶的，它们不会破坏命名空间的目的。相反，它们使名称空间可用。

这是个案。我们希望在软件的生命周期内最大限度地降低软件的“总拥有成本”。声明“using namespace std”有一定的代价，但不使用它也有易读性的代价。

人们正确地指出，当使用它时，当标准库引入新的符号和定义时，您的代码将停止编译，您可能被迫重命名变量。然而，这可能是一个很好的长期目标，因为如果您出于某种令人惊讶的目的使用关键字，未来的维护人员将暂时感到困惑或分心。

你不希望有一个名为vector的模板，比如说，它不是其他人都知道的向量。因此，C++库中引入的新定义的数量非常少，可能根本找不到。必须进行这种更改是有代价的，但代价并不高，而且通过不将std符号名称用于其他目的而获得的清晰性来抵消。

考虑到类、变量和函数的数量，在每一个上声明std:：可能会使代码出错50%，并使您更难理解。一个算法或方法中的一个步骤可以在一屏代码上执行，现在需要前后滚动才能执行。这是一个真实的成本。可以说，这可能不是一个高成本，但那些否认它存在的人是缺乏经验的、教条的，或者根本就是错误的。

我提供以下规则：

std不同于所有其他库。这是每个人基本上都需要知道的一个库，在我看来，最好将其视为语言的一部分。一般来说，使用命名空间std是一个很好的例子，即使没有其他库。永远不要通过将此using放在头中来迫使编译单元（.cpp文件）的作者做出决定。始终将决定权交给编译单元的作者。即使在一个决定在任何地方使用名称空间std的项目中，也可能会有一些模块作为该规则的例外处理。尽管名称空间功能允许您有许多定义相同符号的模块，但这样做会令人困惑。请尽可能保持名称不同。即使不使用名称空间特性，如果您有一个名为foo的类，并且std引入了一个名foo的类型，那么长期来说重命名您的类可能会更好。使用名称空间的另一种方法是通过前缀手动命名符号。我有两个库，我用了几十年，实际上都是从C库开始的，每个符号的前缀都是“AK”或“SCWin”。一般来说，这就像避免使用“using”构造，但不使用双冒号。AK:：foo（）改为AKFoo（）。它使代码更密集5-10%，更不冗长，唯一的缺点是，如果必须使用两个具有相同前缀的这样的库，则会遇到很大的麻烦。注意，X Window库在这方面非常出色，只是它们忘记了使用一些#定义：TRUE和FALSE应该是XTRUE和XFALSE，这与Sybase或Oracle产生了命名空间冲突，它们同样使用了TRUE和FALSE，但值不同！（在数据库的情况下为ASCII 0和1！）这样做的一个特殊优点是，它似乎适用于预处理器定义，而C++使用/命名空间系统不处理它们。这样做的一个好处是，它提供了从项目的一部分到最终成为图书馆的有机坡度。在我的一个大型应用程序中，所有的窗口类都以Win为前缀，所有的信号处理模块都以Mod为前缀等等。这些模块中的任何一个都不太可能被重用，因此将每个组放入一个库中没有实际的好处，但几秒钟后就可以看出项目是如何分解为子项目的。

考虑

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


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

class stringstream {  // Uh oh
};

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

这并不可怕，但如果不在头文件或全局名称空间中使用它，您将省去麻烦。在非常有限的范围内执行它可能是正确的，但我从未遇到过键入额外的五个字符来澄清我的函数来自何处的问题。

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