“使用命名空间 std”有什么问题？

Question

我听说 using namespace std; 是错误的，我应该直接使用 std::cout 和 std::cin 。

这是为什么呢？声明与 std 命名空间中的内容同名的变量是否存在风险？对性能有影响吗？

Answer 1

命名空间是一个命名范围。命名空间用于对相关声明进行分组并保持独立
项目分开。例如，两个单独开发的库可能使用相同的名称来引用不同的库
项，但用户仍然可以使用两者：

namespace Mylib{
    template<class T> class Stack{ /* ... */ };
    // ...
}

namespace Yourlib{
    class Stack{ /* ... */ };
    // ...
}

void f(int max) {
    Mylib::Stack<int> s1(max); // Use my stack
    Yourlib::Stack    s2(max); // Use your stack
    // ...
}

重复命名空间名称可能会分散读者和作者的注意力。因此，有可能
声明来自特定命名空间的名称无需明确限定即可使用。例如：

void f(int max) {
    using namespace Mylib; // Make names from Mylib accessible
    Stack<int> s1(max); // Use my stack
    Yourlib::Stack s2(max); // Use your stack
    // ...
}

命名空间提供了一个强大的工具来管理不同的库和不同版本的代码。特别是，它们为程序员提供了如何显式引用非本地名称的替代方案。

资料来源：C++ 编程语言概述
作者：比亚尼·斯特鲁斯特鲁普

Answer 2

这是一个 using namespace std 因 count 的歧义而引发编译错误的示例，count 也是算法库中的一个函数。

#include <iostream>
#include <algorithm>

using namespace std;

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

Answer 3

这是具体情况而定。我们希望最大限度地降低软件在其生命周期内的“总拥有成本”。声明“使用命名空间 std”会产生一些成本，但不使用它也会在易读性方面产生成本。

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

例如，您想要有一个名为向量的模板，它不是其他人都知道的向量。而且 C++ 库中引入的新定义数量足够少，可能根本不会出现。进行此类更改是有成本的，但成本并不高，并且可以被不将 std 符号名称用于其他目的而获得的清晰度所抵消。

考虑到类、变量和函数的数量，在每个类、变量和函数上都声明 std:: 可能会使您的代码混乱 50%，并使您更难以理解。可以在一屏代码上采用的算法或方法中的步骤现在需要来回滚动才能跟随。这是真实的成本。可以说，这可能成本并不高，但否认它存在的人要么缺乏经验，要么教条主义，或者根本就是错误的。

我提供以下规则：

1. std 与所有其他库不同。它是每个人基本上都需要了解的一个库，在我看来最好将其视为语言的一部分。一般来说，即使其他库没有，使用命名空间 std 也是一个很好的例子。

2. 切勿通过将此 using 放入标头中来将决定强加给编译单元（.cpp 文件）的作者。 始终将决定推迟给编译单元作者。即使在一个已决定在所有地方使用 using namespace std 的项目中，也可能会罚款一些最好作为该规则的例外处理的模块。

3. 尽管命名空间功能允许您拥有许多具有相同定义符号的模块，但这样做会很混乱。尽可能保持名称不同。即使不使用命名空间功能，如果您有一个名为 foo 的类，并且 std 引入了一个名为 foo 的类，从长远来看可能会更好无论如何都要重命名您的类。

4. 使用命名空间的另一种方法是通过给命名空间符号添加前缀来手动命名空间符号。我有两个已经使用了几十年的库，实际上都是从 C 库开始的，其中每个符号都以“AK”或“SCWin”为前缀。一般来说，这就像避免使用“using”结构，但你不写双冒号。 AK::foo() 改为 AKFoo()。它使代码密度增加了 5-10%，并且不再那么冗长，唯一的缺点是，如果您必须使用两个具有相同前缀的此类库，您将遇到大麻烦。请注意，X Window 库在这方面非常出色，只是他们忘记了使用一些 #define 来做到这一点：TRUE 和 FALSE 应该是 XTRUE 和 XFALSE，这与同样使用 TRUE 和 FALSE 的 Sybase 或 Oracle 建立了命名空间冲突具有不同的价值观！ （对于数据库来说是 ASCII 0 和 1！）这一点的一个特殊优点是它可以无缝地应用于预处理器定义，而 C++ using/namespace 系统则不然。不要处理它们。这样做的一个好处是，它提供了从项目的一部分到最终成为图书馆的有机斜坡。在我的一个大型应用程序中，所有窗口类都以 Win 为前缀，所有信号处理模块都以 Mod 为前缀，等等。这些被重用的机会很小，因此将每个组都变成一个库没有任何实际好处，但几秒钟内项目如何分解为子项目就变得显而易见。

Answer 4

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

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

正如页面中提到的：< /p>

使用命名空间std的语句通常被认为是不好的
实践。该语句的替代方法是指定
使用作用域运算符(::) 标识符所属的命名空间
每次我们声明一个类型时。

请参阅此意见：

在源文件中使用“using namespace std”没有问题
当您大量使用名称空间并确定
没有任何东西会发生碰撞。

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

正如页面中提到的：< /p>

尽管该语句使我们不必在任何时候输入 std::
我们希望访问 std 命名空间中定义的类或类型，它
将整个 std 命名空间导入到当前命名空间中
的程序。让我们举几个例子来理解为什么会这样
可能不是什么好事

...

现在在开发的后期阶段，我们希望使用另一个版本
cout 是在一些名为“foo”的库中自定义实现的（对于
示例）

...

请注意，cout 指向哪个库，这是如何存在歧义的？
编译器可能会检测到这一点并且不会编译该程序。在最坏的情况下
在这种情况下，程序可能仍然可以编译但调用错误的函数，因为
我们从未指定标识符属于哪个命名空间。

Answer 5

我同意其他人的观点——它要求名称冲突、含糊不清，但事实是它不太明确。虽然我可以看到 using 的用法，但我个人的偏好是限制它。我也会强烈考虑其他人指出的内容：

如果您想找到一个可能是相当常见的名称的函数名称，但您只想在 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（但这是一个很好的练习，也是让自己 a. 学习另一种语言 b. 尽量不要对对象/类/等有偏见的好方法，这可能是更好的表述思想不那么封闭，不那么傲慢，更容易接受。）。但有用的是一些人已经建议的：我确实使用列表（它相当通用，不是吗？）和排序（相同的东西）来命名两个，如果我要using namespace std;，因此为此目的，我更喜欢具体、可控，并且知道如果我打算将其作为标准用途，那么我将必须指定它。简而言之：不允许假设。

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

Answer 6

根据我的经验，如果您有多个使用 cout 的库，但出于不同的目的，您可能会使用错误的 cout。

例如，如果我输入 using namespace std; 和 using namespace otherlib; 并仅键入 cout （两者恰好都存在） ，而不是 std::cout （或 'otherlib::cout'），您可能会使用错误的，并出现错误。使用 std::cout 更加有效和高效。

Answer 7

我不认为在所有情况下这都一定是不好的做法，但使用时需要小心。如果您正在编写一个库，您可能应该将范围解析运算符与名称空间一起使用，以防止您的库与其他库发生冲突。对于应用程序级别的代码，我没有发现任何问题。

Answer 8

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

Answer 9

为什么要避免using namespace std;？

原因 1：避免名称冲突。

由于 C++ 标准库很大且不断扩展，因此命名空间在 C++ 中用于减少名称冲突。当您使用“using namespace std;”时，您正在批量导入所有内容。

这就是为什么“使用命名空间 std;”永远不会出现在任何专业代码中。

原因2：编译失败。

因为它将std命名空间中定义的数百个东西（类、方法、常量、模板等）拉入全局命名空间。它不仅对写入“using namespace std”本身的文件这样做，而且对包含它的任何文件都递归地这样做。这很容易导致意外的 ODR 违规和难以调试的编译器/链接器错误。

示例：

当您在全局命名空间中声明函数“max”时，您将使用 std 命名空间。

由于您没有使用 cmath 标头，因此一切似乎都运行良好。

当其他人包含您的文件和 cmath 标头时，他们的代码会意外地无法构建，因为全局命名空间中有两个名为“max”的函数。

原因 3：将来可能不起作用。

更糟糕的是，您无法预测将来会对 std:: 命名空间进行哪些更改。这意味着如果新添加的符号与代码中的某些内容发生冲突，今天运行的代码可能会在以后停止运行。

原因 4：难以维护和调试。

使用命名空间 std; 会产生难以维护和调试的代码。这是因为某些方面的来源并不总是显而易见。如果开发人员使用术语“字符串”而没有更多解释，则他们可能指的是 std::string 类或唯一字符串类。

---

带有命名空间std的代码

#include <iostream>
#include <algorithm>

using namespace std;

int swap = 0;

int main() {
    cout << swap << endl; // ERROR: reference to "swap" is ambiguous
}

没有命名空间

#include <iostream>

int main() {
    using std::cout; // This only affects the current function

    cout << "Hello" <<'\n';
}

但是你可以使用if，

• 如果你想制作简短的教程或程序等，你可以使用它。

• 当您大量使用命名空间并且确信不会发生冲突时，在源文件中使用“using namespace std”没有问题。

Answer 10

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

Answer 11

我反过来说：为什么有些人认为额外输入五个字符很麻烦？

例如，考虑编写一个数值软件。当 vector 为 1 时，为什么我会考虑通过将常规 std::vector 缩减为 vector 来污染我的全局命名空间问题领域最重要的概念是什么？

Answer 12

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

using namespace foo;
using namespace bar;

一切正常，您可以从 Foo 调用 Blah() 并从 Bar 调用 Quux() ，不会出现任何问题。但有一天，您升级到了 Foo 2.0 的新版本，它现在提供了一个名为 Quux() 的函数。现在您遇到了冲突：Foo 2.0 和 Bar 都将 Quux() 导入到您的全局命名空间中。这将需要一些努力来修复，特别是如果函数参数恰好匹配的话。

如果您使用过 foo::Blah() 和 bar::Quux()，那么引入 foo::Quux() 将会已经成为一个非事件。

Answer 13

的更糟糕！

它可能会比 Greg写 Foo 2.0 可以引入一个函数 Quux()，对于您对 Quux() 的某些调用来说，它比 bar::Quux( ) 你的代码调用了很多年。然后你的代码仍然可以编译，但是它默默地调用了错误的函数并且做了天知道什么的事情。这就是事情所能达到的最糟糕的情况了。

请记住，std 命名空间有大量标识符，其中许多非常常见（例如 list、sort、string、iterator 等）也很可能出现在其他代码中。

如果您认为这不太可能：Stack Overflow 上有一个问题，几乎正是发生了这种情况（错误的函数称为 due在我给出这个答案大约半年后，省略了 std:: 前缀。 这里是此类问题的另一个最新示例。
所以这是一个真正的问题。

---

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

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

---

底线：明确地为所有内容添加前缀不会造成任何损害，只需很少的时间即可习惯，并且具有客观的优势。特别是，它使代码更容易被编译器和人类读者解释——这可能应该是编写代码时的主要目标。

Answer 14

将 using namespace 放入类的头文件中的问题在于，它迫使任何想要使用您的类（通过包含头文件）的人也“使用”（即查看其中的所有内容）那些其他命名空间。

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

---

请注意，有些人不同意我这样说“随意”——因为虽然 cpp 文件中的 using 语句比标头中的更好（因为它不不会影响包含您的头文件的人），他们认为这仍然不好（因为根据代码，它可能会使类的实现更难以维护）。 此 C++ 超级常见问题解答条目 说，

using-directive 存在于旧版 C++ 代码中，旨在简化到命名空间的转换，但您可能不应该定期使用它，至少不应该在新的 C++ 代码中使用它。

常见问题解答建议了两种替代方案：

• 使用声明：

  使用 std::cout; // using 声明让您无需限定即可使用 cout
  计算<< “价值观：”；
  

• 只需输入 std::

  std::cout << “价值观：”；
  

Answer 15

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

using namespace std;
using namespace boost;

很多 Boost 功能正在纳入 C++0x 标准，而 Visual Studio 2010 有很多 C++0x 功能，因此突然间这些程序无法编译。

因此，避免 using namespace X; 是一种面向未来的形式，一种确保对正在使用的库和/或头文件的更改不会破坏程序的方法。

Answer 16

简短版本：不要在头文件中使用全局 using 声明或指令。请随意在实现文件中使用它们。以下是 Herb Sutter 和 Andrei Alexandrescu 必须在 C++ 编码标准（粗体表示强调是我的）：

摘要

命名空间 using 是为了您的方便，而不是为了您对他人造成伤害：切勿在 #include 指令之前编写 using 声明或 using 指令。

推论：在头文件中，不要编写命名空间级别的 using 指令或 using 声明；相反，显式地对所有名称进行命名空间限定。 （第二条规则遵循第一条规则，因为标头永远无法知道在它们之后可能出现其他标头 #includes。）

讨论

简而言之：您可以而且应该在 #include 指令之后在实现文件中自由地使用命名空间 using 声明和指令，并且对此感觉良好。 尽管不断提出相反的主张，但命名空间使用声明和指令并不是邪恶的，它们不会违背命名空间的目的。相反，它们使命名空间变得可用。

Answer 17

不应在全局范围内使用 using 指令，尤其是在标头中。然而，在某些情况下，即使在头文件中也是合适的：

template <typename FloatType> inline
FloatType compute_something(FloatType x)
{
    using namespace std; // No problem since scope is limited
    return exp(x) * (sin(x) - cos(x * 2) + sin(x * 3) - cos(x * 4));
}

这比显式限定（std::sin、std::cos...）要好，因为它更短并且能够使用用户定义的浮点类型（通过 参数相关查找< /a>（ADL））。

Answer 18

不要在全球范围内使用它

只有在全球范围内使用时才被认为是“坏”的。因为：

• 您正在编程的命名空间变得混乱。
• 当您使用许多 using namespace xyz; 时，读者将很难看到特定标识符的来源。
• 对于源代码的其他读者来说是正确的，对于最常阅读源代码的读者（您自己）来说更是如此。一两年后回来看看...
• 如果您只谈论 using namespace std; 您可能不会意识到您抓取的所有内容 - 当您添加另一个>#include 或迁移到新的 C++ 修订版，您可能会遇到您不知道的名称冲突。

您可以在本地使用它

继续并在本地（几乎）自由地使用它。当然，这可以防止您重复 std:: ——而且重复也是不好的。

在本地使用它的习惯用法

在C++03中，有一个习惯用法——样板代码——用于为类实现交换函数。建议您实际使用本地using namespace std;——或者至少using std::swap;：

class Thing {
    int    value_;
    Child  child_;
public:
    // ...
    friend void swap(Thing &a, Thing &b);
};
void swap(Thing &a, Thing &b) {
    using namespace std;      // make `std::swap` available
    // swap all members
    swap(a.value_, b.value_); // `std::stwap(int, int)`
    swap(a.child_, b.child_); // `swap(Child&,Child&)` or `std::swap(...)`
}

这会产生以下魔力：

• 编译器将选择std::swap 代表 value_，即 void std::swap(int, int)。
• 如果您实现了重载void swap(Child&, Child&)，编译器将选择它。
• 如果您没有该重载，编译器将使用 void std::swap(Child&,Child&) 并尽力交换它们。

对于C++11，没有理由再使用这种模式。 std::swap 的实现已更改，以查找潜在的重载并选择它。

Answer 19

如果导入正确的头文件，您会突然得到类似 hex，左， plus 或 count 在您的全局范围内。如果您不知道 std:: 包含这些名称，这可能会令人惊讶。如果您还尝试在本地使用这些名称，可能会导致相当多的混乱。

如果所有标准内容都在其自己的名称空间中，则不必担心与代码或其他库的名称冲突。

Answer 20

另一个原因是惊喜。

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

Answer 21

我同意它不应该在全局使用，但在本地使用也没有那么邪恶，就像在命名空间中一样。以下是“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 声明声明的名称）优先于通过 using 指令（using namespace Her_lib）在另一个作用域中访问的名称）。

Answer 22

有经验的程序员使用任何可以解决问题的方法，并避免任何产生新问题的方法，并且出于这个确切的原因，他们避免使用头文件级的 using 指令。

经验丰富的程序员也会尽量避免在源文件中对名称进行完全限定。造成这种情况的一个次要原因是，当更少的代码就足够时，编写更多的代码并不优雅，除非有充分的理由。造成这种情况的一个主要原因是关闭参数相关查找（ADL）。

这些充分的理由是什么？有时程序员明确想要关闭 ADL，有时他们想要消除歧义。

因此，以下内容是可以的：

1. 函数实现中的函数级 using-directives 和 using-declarations
2. 源文件中的源文件级 using-declarations
3. （有时） 源文件级 using-directives

Answer 23

我也认为这是一种不好的做法。为什么？就在有一天，我认为命名空间的功能是划分东西，所以我不应该把所有东西都扔进一个全局包里，从而破坏它。

但是，如果我经常使用“cout”和“cin”，我会写： using std::cout;在 .cpp 文件中使用 std::cin;（切勿在头文件中使用，因为它通过 #include 传播）。我认为没有一个理智的人会将流命名为 cout 或 cin。 ;)

Answer 24

很高兴看到代码并知道它的作用。如果我看到 std::cout 我就知道这是 std 库的 cout 流。如果我看到 cout 那我就不知道了。它可能是std库的cout流。或者同一函数中可能有十行以上的 int cout = 0; 。或者该文件中名为 cout 的 static 变量。它可以是任何东西。

现在，采用一百万行代码库，这并不是特别大，并且您正在寻找错误，这意味着您知道这一百万行中有一行没有执行其应该执行的操作。 cout << 1; 可以读取一个名为 cout 的 static int，将其左移一位，然后丢弃结果。寻找错误，我必须检查一下。你能看出我是多么喜欢看到 std::cout 吗？

如果您是一名教师并且从未以编写和维护任何代码为生，那么这似乎是一个非常好的主意。我喜欢看到以下代码：(1) 我知道它的作用；并且，(2) 我相信编写它的人知道它的作用。

Answer 25

这一切都是为了管理复杂性。使用命名空间会引入您不想要的东西，因此可能会使调试变得更加困难（我说可能）。到处使用 std:: 更难阅读（更多文本等等）。

课程马匹 - 以您最好的方式和感觉能够管理您的复杂性。

Answer 26

请

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


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

class stringstream {  // Uh oh
};

注意，这是一个简单的示例。如果您的文件包含 20 个包含项和其他导入项，那么您将需要检查大量依赖项才能找出问题。更糟糕的是，根据冲突的定义，您可能会在其他模块中遇到不相关的错误。

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

Answer 27

一个具体的例子来澄清这个问题。想象一下，您有两个库： foo 和 bar，每个库都有自己的命名空间：

namespace foo {
    void a(float) { /* Does something */ }
}

namespace bar {
    ...
}

现在假设您使用 foo 和 < code>bar 一起在你自己的程序中如下：

using namespace foo;
using namespace bar;

void main() {
    a(42);
}

此时一切都很好。当您运行程序时，它会“执行某些操作”。但稍后您更新了 bar ，假设它已更改为：

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。这是不可取的，但幸运的是它非常简单（只需在编译器标记为不明确的所有对 a 的调用前面添加 foo:: 即可）。

但想象一下另一种情况，其中 bar 改为如下所示：

namespace bar {
    void a(int) { /* Does something completely different */ }
}

此时，您对 a(42) 的调用突然绑定到 bar::a 而不是 >foo::a 并没有做“某事”，而是做“完全不同的事情”。没有编译器警告或任何东西。你的程序只是默默地开始做一些与以前完全不同的事情。

当您使用命名空间时，您将面临这样的情况的风险，这就是人们使用命名空间感到不舒服的原因。命名空间中的事物越多，冲突的风险就越大，因此与其他命名空间相比，人们可能会更不舒服地使用命名空间 std （由于该命名空间中的事物数量）。

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

Answer 28

1. 您需要能够阅读由与您有不同风格和最佳实践观点的人编写的代码。

2. 如果您只使用cout，没有人会感到困惑。但是，当您有很多命名空间，并且您看到此类并且不确定它的作用时，显式命名空间将充当某种注释。乍一看，您可以看到“哦，这是一个文件系统操作”或“这是一个网络操作”。

Answer 29

同时使用许多命名空间显然会导致灾难，但在我看来，仅使用命名空间 std 并且仅使用命名空间 std 并不是什么大问题，因为重新定义可以仅由您自己的代码发生...

因此，只需将它们视为保留名称（如“int”或“class”）即可。

人们不应该再对此如此耿耿于怀。你的老师一直都是对的。只使用一个命名空间；这就是首先使用名称空间的全部意义。您不应该同时使用多个。除非是你自己的。因此，重新定义不会发生。

Answer 30

我同意这里其他人的观点，但我想解决有关可读性的问题 - 您可以通过简单地在文件、函数或类声明的顶部使用 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;
}

或：

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