这是个案。我们希望在软件的生命周期内最大限度地降低软件的“总拥有成本”。声明“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为前缀等等。这些模块中的任何一个都不太可能被重用，因此将每个组放入一个库中没有实际的好处，但几秒钟后就可以看出项目是如何分解为子项目的。

我最近遇到了关于VisualStudio2010的投诉。事实证明，几乎所有的源文件都有这两行：

using namespace std;
using namespace boost;

许多Boost功能将进入C++0x标准，而Visual Studio 2010有许多C++0x功能，因此这些程序突然无法编译。

因此，避免使用名称空间X；是一种未来校对的形式，一种确保对正在使用的库和/或头文件的更改不会破坏程序的方法。

我同意其他人的看法——这是在要求名字冲突、歧义，但事实是它不够明确。虽然我可以看到使用的用途，但我个人倾向于限制它。我也会强烈考虑其他人所指出的：

如果你想找到一个可能是一个相当常见的名称的函数名，但你只想在std命名空间中找到它（或者反过来——你想更改所有不在命名空间std、命名空间X…中的调用），那么你打算怎么做？

你可以编写一个程序来完成它，但花时间在项目本身上而不是编写一个维护项目的程序，这不是更好吗？

就我个人而言，我其实并不介意std:：前缀。我更喜欢它的外观而不是没有它。我不知道这是因为它很明确，并对我说“这不是我的代码……我正在使用标准库”，还是因为它是其他东西，但我觉得它看起来更好。这可能很奇怪，因为我最近才接触C++（使用C和其他语言的时间更长，而且C是我一直以来最喜欢的语言，就在汇编语言之上）。

还有一件事，尽管它与上述内容和其他人指出的内容有些关联。虽然这可能是不好的做法，但我有时会为标准库版本保留std:：name，为特定于程序的实现保留名称。是的，这确实会咬你，咬你很厉害，但归根结底，我是从零开始这个项目的，我是唯一的程序员。例如：我重载std:：string并将其称为string。我有一些有用的补充。我之所以这样做，部分原因是我的C和Unix（+Linux）倾向于小写名称。

除此之外，还可以使用命名空间别名。这里是一个可能没有提到的有用的例子。我使用C++11标准，特别是libstdc++。它没有完全的std:：regex支持。当然，它可以编译，但它会抛出一个异常，这是程序员端的错误。但它缺乏实施。

下面是我解决这个问题的方法。安装Boost的正则表达式，并将其链接进来。然后，我执行以下操作，以便在libstdc++完全实现它时，我只需删除这个块，代码保持不变：

namespace std
{
    using boost::regex;
    using boost::regex_error;
    using boost::regex_replace;
    using boost::regex_search;
    using boost::regex_match;
    using boost::smatch;
    namespace regex_constants = boost::regex_constants;
}

我不会争论这是不是个坏主意。然而，我会争辩说，它为我的项目保持了干净，同时又使它变得具体：没错，我必须使用Boost，但我使用它就像libstdc++最终会使用它一样。是的，启动自己的项目并从一开始就使用标准（…）对帮助维护、开发和项目所涉及的一切都有很大的帮助！

只是想澄清一下：我实际上并不认为在STL中使用类名或其他名称来代替它是一个好主意。字符串对我来说是个例外（忽略第一个，上面的，或者这里的第二个，如果必须的话双关语），因为我不喜欢“字符串”这个概念。

事实上，我仍然非常倾向于C和C++。省略细节，我所做的很多工作更适合C（但这是一个很好的练习，也是让自己学会另一种语言的好方法）。不要对对象/类等抱有偏见，这可能更好地表述为不那么封闭、不那么傲慢、更容易接受。）。但有用的是一些人已经提出的建议：我确实使用了列表（它相当通用，不是吗？），并排序（相同的事情）以命名两个，如果我使用名称空间std；，因此，为了达到这个目的，我更喜欢具体、可控，并且知道如果我打算将其作为标准用途，那么我必须指定它。简单地说：不允许假设。

至于让Boost的正则表达式成为标准的一部分。我这样做是为了将来的集成，而且——再次，我完全承认这是偏见——我不认为它像Boost:：正则表达式：：。。。。事实上，这对我来说是另一回事。C++中有很多东西我还没有完全接受，包括外观和方法（另一个例子：varadic模板与var参数[尽管我承认varadic模版非常有用！]）。即使那些我确实接受的人也很困难，我仍然对他们有意见。

我认为本地或全球使用应取决于应用程序。

因为，当我们在本地使用库时，有时代码会变得一团糟。可读性将下降。

因此，只有在可能发生冲突时，我们才应该在本地使用库。

我不是一个更有经验的人。所以，如果我错了，请告诉我。

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

这可能比Greg写的更糟！

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

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

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

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

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

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