“使用命名空间std;＆quot”的问题是什么？

Question

我已经听到使用命名空间std;是错误的，并且我应该使用std :: cout和std :: cin cin直接而代替。

为什么这是？它是否会宣布与std名称空间中的内容相同名称的变量？有绩效影响吗？

Answer 1

1. 您需要能够读取与您不同的风格和最佳实践意见的人所写的代码。

2. 如果您仅使用cout，没有人会感到困惑。但是，当您有很多名称空间，您会看到此类班级，而您不确定它的作用时，将命名空间显式充当各种评论。乍一看，您可以看到“哦，这是一个文件系统操作”或“在做网络工作”。

Answer 2

同时使用许多名称空间显然是灾难的秘诀，但是仅使用命名空间std，而名称空间std在我看来并不是什么大事，因为重新定义可以重新定义仅通过您自己的代码出现...

因此，只需将它们视为保留名称，例如“ int”或“ class”，仅此而已。

人们应该停止对此感到肛门。您的老师一直是对的。只需使用一个名称空间；这是首先使用名称空间的重点。您不应该同时使用多个。除非它是你自己的。因此，重新定义不会发生。

Answer 3

我同意这里的其他人，但是我想解决有关可读性的担忧 - 您可以通过简单地使用文件，功能或类声明的顶部的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;
}

Answer 4

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

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 ++编程语言的概述
由Bjarne Stroustrup

Answer 5

其中使用命名空间std的一个示例由于计数的歧义而引发了汇编错误，这也是算法库中的函数。

#include <iostream>
#include <algorithm>

using namespace std;

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

Answer 6

这是情况下的情况。我们希望最大程度地减少该软件在其寿命中的“总拥有成本”。说“使用命名空间std”有一定的成本，但是 使用它也具有可读性的成本。

人们正确地指出，当使用标准库引入新的符号和定义时，您的代码将停止编译，并且您可能被迫重命名变量。但是，这可能是长期的，因为如果您将关键字用于某些令人惊讶的目的，将来的维护者将暂时混淆或分心。

您不希望 拥有一个称为向量的模板，例如，这不是其他所有人都知道的向量。并且在C ++库中如此引入的新定义数量很小，可能根本不会出现。 是必须进行这种更改的成本，但是成本不是很高，并且由于不使用std符号而获得的清晰度所抵消，以抵消。

鉴于类，变量和功能的数量，说明std ::在每个人的代码上可能会增加50％，并使您的头部更加困难。现在，可以在一个屏幕上使用的算法或逐步使用一个屏幕代码，需要来回滚动才能遵循。这是一个真正的成本。可以说，这可能不是很高的成本，但是否认它的人甚至没有经验，教条或简直是错误的。

我将提供以下规则：

1. std与所有其他库不同。这是每个人基本上都需要知道的一个库，我认为最好将其视为语言的一部分。一般而言，即使没有其他库

2. 切勿通过在标题中使用将此放入编译单元（.cpp文件）的作者（.cpp文件）。 始终将决定推迟给编译单元作者。即使在一个决定使用使用命名空间std的项目中，到处都可以填补一些最佳将作为该规则例外的模块。

3. 即使命名空间功能使您拥有许多具有相同符号的模块，但这样做会感到困惑。在可能的程度上保持名称不同。即使不使用命名空间功能，如果您的类名为foo和std引入了名为foo的类无论如何，要重命名您的课程。

4. 使用名称空间的一种替代方法是通过将其前缀前缀来手动命名空间符号。实际上，我有两个我使用的库，这些库是从C库开始的，其中每个符号都带有“ AK”或“ SCWIN”。一般来说，这就像避免使用“使用”构造，但您不写双结肠。 ak :: foo（）是akfoo（）。它使代码使代码5-10％浓密且详细，唯一的缺点是，如果您必须使用两个具有相同前缀的库，那么您会遇到大麻烦。请注意，X窗口库在这方面非常出色，除了它们忘了使用一些#Defines这样做：True and False应该是Xtrue和Xfalse，并且与Sybase或Oracle建立了同样使用的Sybase或Oracle的命名空间冲突有不同的值！ （在数据库的情况下ASCII 0和1！）这样的一个特殊优势是，它似乎不适用于预处理器定义，而C ++ 使用//namespace namespace system do do do d'' T处理它们。一个很好的好处是，它从成为项目的一部分到最终成为图书馆的有机斜率。在我的大型应用中，所有窗口类都均为win，所有信号处理模块mod等等。将其中的任何一个重复使用的可能性很小，因此将每个组进入图书馆没有实际好处，但是在几秒钟内，该项目如何分解为子项目。

Answer 7

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

名称空间std包含C ++标准功能和变量。当您经常使用C ++标准功能时，此名称空间很有用。

如此 page ：：< /p>

使用命名空间std的语句通常被认为是不好的
实践。该语句的替代方法是指定
标识符使用示波器操作员（：:)属于的名称空间
每次我们声明类型。

并参见 a>：

在源文件中使用“使用命名空间std”没有问题
当您大量使用命名空间并确定
什么都不会碰撞。

有人说过，在源文件中使用名称空间std 包括是一个不好的做法，因为您正在从该命名空间中调用所有函数和变量。当您想定义具有与名称空间std中包含的另一个函数相同名称的新功能时，您会超载该功能，并且由于编译或执行而可能会产生问题。它不会按照您的期望进行编译或执行。

如此 page ：：< /p>

尽管该语句使我们免于键入std ::
我们希望访问在STD名称空间中定义的类或类型
将整个性病名称空间导入当前名称空间
程序。让我们以一些例子来理解为什么
可能不是一件好事

...

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

...

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

Answer 8

我同意别人的观点 - 它要求姓名冲突，歧义，然后事实是它不太明确。虽然我可以看到使用的使用，但我的个人喜好是限制它。我还将强烈考虑其他一些人指出的：

如果您想找到一个可能是相当通用名称的函数名称，但是您只想在std sand> namespace（或反向 - 反向 -您想更改名称空间中的所有 std ，namespace x ...）的调用，然后您如何建议这样做？

您可以编写一个程序来执行此操作，但是花时间花时间在您的项目本身上工作，而不是编写程序来维护您的项目吗？

就个人而言，我实际上不介意std ::前缀。我喜欢它不拥有它。我不知道那是因为它是明确的，并对我说：“这不是我的代码...我正在使用标准库”，或者它是否是其他东西，但我认为它看起来更好。鉴于我直到最近才进入C ++（使用C ++（在更长的时间里），C是我有史以来最喜欢的语言，在汇编之上是我最喜欢的语言）。

还有另一件事，尽管它与上述内容有些相关，而其他人则指出了什么。虽然这可能是不好的练习，但我有时保留std ::名称用于标准库版本和针对特定程序的实现名称。是的，的确，这可能会咬您并用力地咬您，但这一切都取决于我从头开始启动这个项目，而我是唯一的程序员。示例：i Overload 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 ++最终将拥有它。是的，启动自己的项目并从一开始就以标准（...）开始，在帮助维护，开发以及项目所涉及的所有内容方面有很长的路要走！

只是为了澄清一些事情：我实际上并不认为使用class的名称/ stl 故意，更具体地代替。字符串是例外（我不喜欢“字符串”的想法，请忽略第一个，上方或第二个，如果您必须的话，如果您需要的话，请忽略它。

实际上，我仍然对C偏见，并且对C ++有偏见。保留细节，我在工作中工作的大部分都更适合C（但这是一个很好的练习，也是使自己A的好方法。学习另一种语言和b。请不要偏爱对象/class/class/ett，这也许更好地说明了不太封闭，不太自大，更接受。）。但是，什么 有用的是一些已经提出的建议：我确实使用列表（这是相当通用的，不是吗？我要使用名称空间std; 进行，因此，我更喜欢在控制方面进行特定，并且知道如果我打算将其作为标准用途，那么我将不得不指定它。简单地说：不允许假设。

至于使Boost的REGEX部分STD。我这样做是为了将来集成，而且 - 再次承认这是偏见 - 我认为它不像boost :: Regex :: ... ...那样丑陋。确实，这对我来说是另一件事。 C ++中有很多事情，我仍然尚未完全接受外观和方法（另一个示例：variadic模板与var参数[尽管我承认variadic模板非常有用！]）。即使我接受的那些很困难，和我仍然有问题。

Answer 9

从我的经验来看，如果您有多个使用Say的库Cout，但是出于不同的目的，您可以使用错误的cout。

例如，如果我键入，请使用namespace std; and 使用namesp eletherlib; and offe cout（恰好在两者中） ，而不是std :: cout（或'otherlib :: cout'），您可能会使用错误的一个并获取错误。使用std :: cout更有效和有效。

Answer 10

我认为在所有情况下，这都不是不良习惯，但是在使用时，您需要小心。如果您正在编写库，则可能应该使用带有名称空间的范围分辨率运算符，以防止您的库与其他图书馆捆绑。对于应用程序级代码，我没有发现任何问题。

Answer 11

使用不合格的导入标识符，您需要外部搜索工具，例如 grep ，以找出声明标识符的位置。这使得有关程序正确性的推理更加困难。

Answer 12

为什么要避免使用命名空间std; ？

原因1：避免名称碰撞。

，因为C ++标准库很大并且不断扩展在C ++中用于减少名称碰撞。当您使用“使用命名空间std”时，您将批发所有内容。

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

原因2：汇编失败。

因为它将数百件（类，方法，常数，模板等）拉到 std namepace中定义的东西（类，方法，常数，模板等）。它这样做，不仅是针对写入“使用名称空间std”本身的文件，而且还用于递归包含它的任何文件。这很容易导致偶然的 odr 违规和难以实现的违规行为和难以访问debug compiler/linker错误。

示例：

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

由于您没有使用 cmath 标题，因此一切似乎都很好。

当其他人包括您的文件和 cmath 标题时，他们的代码意外构建，因为在全局名称空间中有两个功能，名称为“ max”。

原因3：将来可能无法使用。

更糟糕的是，您无法预测将来对 std :: 名称空间的更改。这意味着，如果新添加的符号与代码中的某些内容发生冲突，那么今天功能的代码可能会在以后的稍后起作用。

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

使用命名空间std; 可能会产生难以维护和难以删除的代码。这是由于以下事实：某些方面的来源并不总是很明显。如果开发人员使用术语“字符串”而无需更多说明，则可能指的是 std :: string 类或唯一的字符串类。

---

带有namespace std 的代码

#include <iostream>
#include <algorithm>

using namespace std;

int swap = 0;

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

没有namepace

#include <iostream>

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

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

，但是您可以使用，如果，

• 您可以使用该简短教程或程序等，等等。

• 您可以使用它， >

Answer 13

这通常被称为全球名称空间污染。当多个命名空间具有带有签名的功能名称相同的功能名称时，可能会发生问题，那么编译器决定要拨打哪个名称是模棱两可的，并且当您使用函数调用指定名称空间（如）时，可以避免所有这些。 std :: cout。

Answer 14

要回答您的问题，我实际上是这样看的：许多程序员（并非全部）调用名称空间std。因此，人们应该习惯于不使用构成与名称空间性标准相同名称的事物。这是一笔巨大的批准，但与可能会严格说出的可能相干词和化名的数量相比，这并不是很多。

我的意思是说……说“不要依靠这个存在”只是让您依靠它不存在。您将不断遇到借用代码片段并不断修理它们的问题。只要将用户定义和借来的东西保持在有限的范围内，并且要对全球群体非常差异（老实说，Globals几乎应该总是为“现在的汇编，以后的理智”而成为最后的手段）。确实，我认为这是您老师的不好建议，因为使用性病将适用于“ COUT”和“ STD :: COUT”，但不使用STD仅适用于“ STD :: COUT”。您不会总是很幸运地编写自己的所有代码。

注意：直到您真正了解编译器的工作方式，请不要过多地关注效率问题。有了一些经验，您就不必在意识到他们能够将良好的代码概括为简单的东西之前就不必了解它们。每一点都像您在C中写整个内容一样简单。良好的代码仅是必要的复杂。

Answer 15

考虑两个称为foo and bar的库：

using namespace foo;
using namespace bar;

一切正常，您可以从foo中调用blah（），而quux（） bar毫无问题。但是有一天，您可以升级到新版本的Foo 2.0，该版本现在提供了一个称为quux（）的函数。现在，您已经发生了冲突：FOO 2.0和BAR导入Quux（）进入您的全局名称空间。这将需要一些努力来修复，尤其是在功能参数恰好匹配的情况下。

如果您使用过foo :: blah（） and bar :: quux（），那么foo :: quux（）的介绍将是一个非事件。

Answer 16

它可能会变得更糟比 greg写作！

图书馆FOO 2.0可以引入一个函数，quux（），对于quux（）> bar :: quux（quux（ ）您的代码已打电话多年。然后，您的 代码仍然编译 ，但是 它默默地称为错误的函数 ，并且上帝知道什么。那和事情一样糟糕。

请记住，std名称空间具有大量标识符，其中许多是非常 common的标识符（think list，sort 代码>，字符串，iterator等）也很可能出现在其他代码中。

如果您不太可能考虑：有一个问题在堆栈溢出上，这几乎是正确的（应得的错误的功能）省略std ::前缀）大约在我给出答案后半年。 在这里是一个问题的另一个最新示例。
因此，这是一个真正的问题。

---

这是另一个数据点：很多年前，我还发现它很烦人，必须将标准库中的所有内容都带有std ::。然后，我在一个项目中工作，一开始就确定使用指令和声明两种均被禁止使用功能范围。猜怎么着？我们大多数人花了几周的时间才习惯编写前缀，几周后，我们中的大多数人甚至同意它实际上使代码更可读。这样做是有原因的： 您不喜欢缩短还是更长的散文是主观的，但是前缀客观地增加了代码。发现更容易查看所引用哪个标识符。

在十年的时间里，该项目越来越多地拥有数百万行代码。由于这些讨论一次又一次进行，因此我曾经很好奇（允许的）功能 - cope 使用实际使用的频率。我抓住了它的来源，只找到了使用它的一个或二十二个地方。对我来说，这表明，一旦尝试过，开发人员就找不到std ::痛苦的痛苦，即使在允许使用的情况下，甚至每100 kloc都使用指令。

---

最重要的是：明确的前缀一切都不会造成任何伤害，几乎没有习惯，并且具有客观的优势。特别是，它使编译器和人类读者可以更容易解释代码 - 这可能是编写代码时的主要目标。

Answer 17

使用名称空间在类的标题文件中放置的问题是，它迫使任何想要使用您的类（通过包括标头文件）的人也可以“使用”（即看到所有内容）那些其他名称空间。

但是，您可能可以随时在（私有） *.cpp文件中列出使用语句。

---

当心有些人不同意我的意见“自由”这样 - 因为尽管使用在cpp文件中使用语句的 比标题更好（因为它没有 T会影响包含您的标头文件的人），他们认为它仍然不是 good （因为取决于代码，它可能会使类实现更难以维护）。 此c ++ super-faq条目说，

存在用于传统C ++代码并简化过渡到名称空间的使用指导性，但您可能不应该定期使用它，至少不在新的C ++代码中。

FAQ提出了两种替代方法：

• a使用销量：

   使用std :: cout; //使用declaration允许您在没有资格的情况下使用cout
  cout＆lt;＆lt; “价值：”;
   

• 只是键入std ::

    std :: Cout＆lt;＆lt; “价值：”;
   

Answer 18

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

using namespace std;
using namespace boost;

很多 Boost 功能已进入C ++ 0x标准，并且Visual＆nbsp“ Studio＆nbsp; 2010具有很多C ++ 0x功能，因此突然间，这些程序没有编译。

因此，避免使用命名空间X; 是对未来预处理的一种形式，这是确保更改库和/或使用中标题文件的一种方式，不会破坏程序。

Answer 19

简短版本：不要使用声明或标题文件中的指令使用全局。随时在实现文件中使用它们。这是 herb sutter and andrei alexandrescu 必须在 C ++编码标准（强调重点是我的）：

摘要

命名空间的使用是为了方便的，而不是为了您的其他人：切勿在#include指令之前编写使用声明或使用指令。

推论：在标题文件中，请勿使用指令或使用声明编写名称空间级别；相反，明确命名空间qualify所有名称。 （第二条规则是从第一个规则开始的，因为标题永远无法知道其他标题可能会出现在它们之后。）

讨论

简而言之：您可以并且应该在#include指令之后使用声明和指令使用命名空间，并对此感到满意。 尽管反复断言相反，但使用声明和指示的名称空间并不是邪恶的，它们不会击败名称空间的目的。相反，它们是使名称空间可用的原因。

Answer 20

一个人不应在全局范围，尤其是标题中使用指令使用。但是，在某些情况下，即使在标题文件中也是合适的：

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 ...），因为它较短并且具有与用户定义的浮点类型一起工作的能力（通过（adl））。

Answer 21

在全球范围内不要使用它，

只有当使用全球时，才被认为是“不良”。因为：

• 您将命名空间弄乱了。
• 当您使用名称空间xyz; 使用许多时，读者很难看到特定标识符的来源。
• 对于其他源代码的读者来说，对于最常见的阅读器而言，源代码的读者更为正确：您自己。一两年后回来，然后看看...
• 如果您仅使用名称空间std来谈论您可能不知道您抓住的所有东西 - 当您添加另一个#include 或移至新的C ++修订版，您可能会发现您不知道的名称冲突。

您可以在本地使用它

，并在本地（几乎）自由使用。当然，这可以阻止您重复std :: - 重复也很不好。

在 c ++ 03 中使用它本地使用的成语

，有一个成语 - 样板代码 - 用于实现您的类。建议您实际上使用local 使用命名空间std; - 或至少使用std :: swap; 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 ::交换 <代码>值_ ，即void std :: swap（int，int）。
• 如果您有一个过载void交换（Child＆amp;，child＆amp;）实施的编译器将选择它。
• 如果您执行不是，则编译器将使用void std :: swap（child＆amp;，child＆amp;），并尝试最佳交换这些。

使用 C ++ 11 没有理由再使用此模式了。更改了std ::交换的实现，以找到潜在的过载并选择它。

Answer 22

如果导入正确的标头文件，则突然有名称，例如 hex， left， plus 或 count 在您的全局范围中。如果您不知道std ::包含这些名称，这可能会令人惊讶。如果您还尝试在本地使用这些名称，则可能会导致一些混乱。

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

Answer 23

另一个原因是惊喜。

如果我看到cout＆lt;＆lt; blah，而不是std :: cout＆lt;＆lt; blah我认为：这是什么cout？它是普通cout吗？这是特别的吗？

Answer 24

我同意它不应在全球使用，但是在本地使用它并不是那么邪恶，例如namepace。这是“ 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诸如使用解析声明的名称）优先于在另一个范围内使用的名称（使用名称sher_lib ） ）。

Answer 25

经验丰富的程序员使用任何解决问题的方法，并避免出现新问题的任何问题，并且由于这个确切的原因，他们避免使用领域的标头文件级别。

经验丰富的程序员还尝试避免源文件中的名称的完全资格。这样做的一个小原因是，除非有充分的理由，否则编写更多代码时，编写更多代码并不优雅。造成这种情况的主要原因是关闭与参数有关的查找（ADL）。

这些是什么好理由？有时，程序员明确想关闭ADL，而其他时候他们想歧义。

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

1. 函数级别使用指导和在函数实现中使用declarations在
2. 源文件中使用declarations在源文件中
3. （有时）使用directives内部使用declarations（有时）

Answer 26

我也认为这是一种不好的做法。为什么？仅一天，我就认为名称空间的功能就是分割东西，因此我不应该将所有东西都扔进一个全球袋子而破坏。

但是，如果我经常使用“ cout”和“ cin”，我会写：使用std :: cout;在.cpp文件中使用std :: cin;（在标头文件中都不在#include传播时，它从不在标题文件中。我认为没有一个理智会命名流COUT或cin。 ）

Answer 27

很高兴看到代码并知道它的作用。如果我看到std :: cout我知道那是cout std库的流。如果我看到cout，那么我不知道。 可以是cout std库的流。或者可能有一个int cout = 0;在同一函数中高十行。或该文件中的static变量名为cout。可能是什么。

现在采用一百万行代码基库，这并不是特别大，您正在寻找一个错误，这意味着您知道这一百万行中有一行不做应该做的事情。 cout＆lt;＆lt; 1;可以读取static int命名cout，将其向左移动一点，然后丢弃结果。寻找错误，我必须检查一下。您能看到我真的更喜欢看std :: Cout吗？

如果您是老师，并且不必为谋生而写任何代码，那么这似乎是一个非常好主意。我喜欢看代码（1）我知道它的作用；而且，（2）我有信心写它的人知道它的作用。

Answer 28

这一切都是关于管理复杂性。使用命名空间会吸引您不想要的东西，因此可能会更难调试（我说）。在整个地方使用STD ::更难阅读（更多文本等）。

课程的马匹 - 管理您的复杂性，如何最好和有能力。

Answer 29

请

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


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

class stringstream {  // Uh oh
};

注意，这是一个简单的示例。如果您的文件具有20个包含和其他导入的文件，则需要大量的依赖项来弄清楚问题。最糟糕的是，您可以根据冲突的定义在其他模块中获得无关的错误。

这不是可怕的，但是您会通过在标头文件或全局名称空间中使用它来节省自己的头痛。在非常有限的范围内进行操作可能是正确的，但是我从来没有遇到过额外的五个字符来阐明我的功能来自何处的问题。

Answer 30

一个具体的例子来澄清关注点。想象一下，您有一个有两个库，foo和bar，每个库都有自己的名称空间：

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

namespace bar {
    ...
}

现在，假设您使用foo和<代码> 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 。这是不希望的，但是幸运的是，这很容易（只需在所有调用中添加foo :: 编译器标记为模棱两可的）。

但是，想象一个替代场景，bar更改为看起来像这样：

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

此时，您的调用a（42）突然绑定到bar :: A而不是> foo :: a，而不是做“某件事”，而是做“完全不同的事”。没有编译器警告或任何内容。您的程序只是默默地开始做与以前完全不同的事情。

当您使用名称空间时，您会冒着这样的场景的危险，这就是为什么人们使用名称空间感到不舒服的原因。命名空间中的东西越多，冲突的风险就越大，因此，使用名称空间std（由于该名称空间中的事物数），人们可能比其他名称空间更加不舒服。

最终，这是可靠性/可靠性之间的权衡。可读性也可能因素，但是我可以看到这两种方式的论据。通常，我会说可靠性和可维护性更为重要，但是在这种情况下，您将不断支付撰写能力成本，以产生相当罕见的可靠性/可维护性的影响。 “最佳”权衡将决定您的项目和优先事项。