我同意这里的其他观点，但我想解决有关可读性的问题——您可以通过在文件、函数或类声明的顶部使用typedef来避免所有这些问题。

我通常在类声明中使用它，因为类中的方法倾向于处理类似的数据类型（成员），typedef是一个在类上下文中分配有意义的名称的机会。这实际上有助于类方法定义的可读性。

// Header
class File
{
   typedef std::vector<std::string> Lines;
   Lines ReadLines();
}

在实施过程中：

// .cpp
Lines File::ReadLines()
{
    Lines lines;
    // Get them...
    return lines;
}

而不是：

// .cpp
vector<string> File::ReadLines()
{
    vector<string> lines;
    // Get them...
    return lines;
}

or:

// .cpp
std::vector<std::string> File::ReadLines()
{
    std::vector<std::string> lines;
    // Get them...
    return lines;
}

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

我不认为这在任何情况下都是不好的做法，但在使用它时都需要小心。如果你正在编写一个库，你可能应该在命名空间中使用作用域解析运算符，以防止你的库与其他库冲突。对于应用程序级代码，我看不出它有什么问题。

这里有一个我在其他答案中都没有找到的观点：只使用一个名称空间。根据大多数答案，命名空间不好的主要原因是，你可能会有冲突的函数名，这会导致一片混乱。但是，如果只使用一个名称空间，则不会发生这种情况。确定您将使用最多的库（可能使用名称空间std；）并坚持使用它。

可以认为它有一个不可见的库前缀-std:：vector变成了vector。在我看来，这是两全其美的：一方面，它减少了必须进行的键入（正如名称空间所预期的那样），另一方面，为了清晰和安全，它仍然需要使用前缀。如果有一个函数或对象没有名称空间前缀，那么您知道它来自您声明的一个名称空间。

请记住，如果您决定在全球范围内使用一个，请不要在本地使用其他。这又回到了其他答案，即本地名称空间通常比全局名称空间更有用，因为它们提供了各种便利。

只要在头文件中不使用“using namespace std”，这应该是完全正常的。

如果与say boost有命名冲突，那么在特定的.cpp文件中不使用此语句，但通过在其他文件中的每一行上不重复“std:：”十次，仍然可以保存每个人的眼睛和手指。

不幸的是，现在这是一个纯粹的宗教问题，每个人都更容易/更有效地遵循一遍又一遍重复“std:：”的既定模式。

我同意不应该在全球范围内使用它，但在本地使用它并没有那么糟糕，就像在命名空间中一样。下面是“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）在另一个作用域中可访问的名称。