一个例子是，使用名称空间std会因为计数的模糊性而引发编译错误，这也是算法库中的一个函数。

#include <iostream>
#include <algorithm>

using namespace std;

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

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

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

这是一种糟糕的做法，通常被称为全局命名空间污染。当多个名称空间具有相同的函数名和签名时，可能会出现问题，那么编译器决定调用哪个名称空间是不明确的，当您使用std:：cout这样的函数调用指定名称空间时，这一切都可以避免。希望这有帮助。：）

考虑

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


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

class stringstream {  // Uh oh
};

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

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

另一个原因是惊讶。

如果我看到cout<<blah，而不是std:：cout<<blah，我会想：这是什么cout？这是正常的服装吗？有什么特别的吗？

考虑两个名为Foo和Bar的库：

using namespace foo;
using namespace bar;

一切都很好，你可以从Foo调用Blah（），从Bar调用Qux（）。但有一天你升级到了Foo 2.0的新版本，它现在提供了一个名为Qux（）的函数。现在出现了一个冲突：Foo 2.0和Bar都将Qux（）导入到全局命名空间中。这将需要一些努力来解决，特别是如果函数参数恰好匹配。

如果您使用了foo:：Blah（）和bar:：Qux（），那么引入foo:：Qux（）将是一个非事件。