我同意不应该在全球范围内使用它，但在本地使用它并没有那么糟糕，就像在命名空间中一样。下面是“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 clash in favor of His_lib
    using Her_lib::Vector; // Resolve potential clash in favor of Her_lib

}

在本例中，我们解决了由它们的组合引起的潜在名称冲突和歧义。

在那里显式声明的名称（包括通过使用His_lib:：String等声明声明的名称）优先于通过using指令（使用名称空间Her_lib）在另一个作用域中可访问的名称。

是的，名称空间很重要。在我的项目中，我需要将一个var声明导入到源代码中，但在编译时，它与另一个第三方库冲突。

最后，我不得不用其他方法来解决这个问题，并使代码变得不那么清晰。

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

考虑

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


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

class stringstream {  // Uh oh
};

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

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

在类的头文件中使用名称空间的问题在于，它迫使任何想要使用您的类（通过包括头文件）的人也“使用”（即查看其他名称空间中的所有内容）。

但是，您可以随意在（私有）*.cpp文件中放入using语句。

请注意，有些人不同意我这样说的“感觉自由”，因为尽管cpp文件中的using语句比头文件中的要好（因为它不会影响包含头文件的人），但他们认为这仍然不好（因为根据代码的不同，这可能会使类的实现更难维护）。这个C++超级FAQ条目说，

using指令存在于遗留的C++代码中，用于简化向命名空间的转换，但您可能不应该定期使用它，至少不应该在新的C++代码。

常见问题解答建议了两种选择：

使用声明：使用std:：cout；//using声明允许您无条件使用coutcout<<“值：”；只需键入std:：std:：cout<<“值：”；

它不会使您的软件或项目性能更差。在源代码开头包含名称空间还不错。using namespace std指令的包含根据您的需求以及开发软件或项目的方式而有所不同。

命名空间std包含C++标准函数和变量。当您经常使用C++标准函数时，这个名称空间非常有用。

如本页所述：使用命名空间std的语句通常被认为是错误的实践此语句的替代方法是指定使用作用域运算符（：：）将标识符所属的命名空间每次我们声明一个类型。请参阅以下意见：在源文件中使用“using namespace std”没有问题当您大量使用命名空间并确信任何东西都不会碰撞。

有些人曾说过，在源文件中包含using命名空间std是一种不好的做法，因为您正在从该命名空间调用所有函数和变量。当您想定义一个与命名空间std中包含的另一个函数同名的新函数时，您会重载该函数，因为编译或执行可能会产生问题。它不会像您期望的那样编译或执行。

如本页所述：尽管该语句使我们不必在任何时候输入std:：我们希望访问std命名空间中定义的类或类型将整个std命名空间导入当前命名空间该计划的一部分。让我们举几个例子来理解为什么可能不是什么好事...现在，在开发的后期阶段，我们希望使用cout是在某个名为“foo”的库中自定义实现的（用于示例）...注意这里有一个歧义，cout指向哪个库？编译器可能会检测到这一点，而不会编译程序。在最坏的情况下在这种情况下，程序仍可能编译，但调用了错误的函数，因为我们从未指定标识符属于哪个命名空间。