这与表演一点关系都没有。但是考虑一下:您使用的是两个名为foo和bar的库:

using namespace foo;
using namespace bar;

一切正常,你可以打电话 Blah() 从FO和 Quux() 从酒吧出来没问题。但是有一天你升级到了新版本的foo 2.0,它现在提供了一个名为 库克斯( . 现在您遇到了一个冲突:foo 2.0和bar导入 Qux() 到全局命名空间中。这需要花费一些精力来修复,特别是当函数参数恰好匹配时。

如果你曾经用过 foo::Blah() 和 bar::Quux() ,然后介绍 foo::Quux() 本来是不重要的。

我同意一切 Greg wrote ,但我想补充一点: 比格雷格说的还要糟!

库foo 2.0可以引入一个函数, Quux() ,对于您的某些呼叫来说,这无疑是更好的匹配 Qux() 比 bar::Quux() 你的代码需要很多年。那么你的 代码仍在编译 但是 它静默地调用错误的函数 上帝知道吗?这是最坏的情况。

记住 std 命名空间包含大量的标识符,其中许多标识符 非常 常见的(思考 list , sort , string , iterator 等)也很可能出现在其他代码中。

如果你认为这不太可能:有 a question asked 在堆栈溢出中,几乎完全发生了这种情况(由于省略而调用了错误的函数 std:: 前缀)我给出这个答案大约半年后。 Here 是这类问题的另一个最近的例子。 所以这是一个真正的问题。

这里还有一个数据点:许多年前,我还发现在标准库的所有内容前面加上前缀会让人恼火 标准: . 然后我在一个项目中工作,在开始的时候决定 using 除函数作用域外,禁止使用指令和声明。你猜怎么着?我们中的大多数人花了几周时间习惯于写前缀,几周之后,我们中的大多数人甚至都同意它确实生成了代码。 更可读 . 这是有原因的: 不管你喜欢短文还是长文都是主观的,但是前缀客观地增加了代码的清晰度。 不仅编译器,而且您也发现更容易看到引用了哪个标识符。

在十年的时间里,这个项目增加到了几百万行代码。由于这些讨论一次又一次地出现,我曾经好奇(允许的)功能范围的频率 使用 实际上是在项目中使用的。我找到了它的来源,只找到了一两打使用它的地方。对我来说,这表明,一旦尝试过,开发人员就不会发现 标准: 即使每100 kloc使用一次指令,即使在允许使用的情况下,也很痛苦。

最重要的是:明确地预加前缀不会造成任何伤害,很少需要习惯,并且有客观的优势。尤其是,它使编译器和人类读者更容易理解代码,这可能是编写代码时的主要目标。

推杆的问题 using namespace 在类的头文件中,它强制任何想要使用类(通过包括头文件)的人也“使用”(即查看其中的所有内容)那些其他名称空间。

但是,您可以在(private).cpp文件中随意放置using语句。

请注意,有些人不同意我这样的说法,因为尽管cpp文件中的using语句 更好的 而不是在头文件中(因为它不影响包含头文件的人),他们认为它仍然不是 好的 (因为依赖于代码,它可能会使类的实现更难维护)。 This FAQ topic 说,

使用指令存在于旧式C++代码中,并简化了向命名空间的转换,但您可能不应该定期使用它,至少在新的C++代码中不应该如此。

常见问题解答提出了两种备选方案:

• 使用声明:

  using std::cout; // a using-declaration lets you use cout without qualification
  cout << "Values:";
  

• 只需输入标准:

  std::cout << "Values:";
  

我最近遇到一个关于 Visual Studio 2010 . 结果发现几乎所有的源文件都有这两行:

using namespace std;
using namespace boost;

很多 Boost 特性进入了C++0X标准,VisualStudioStudio 2010有很多C++ 0x特性,所以这些程序突然没有编译。

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

短版本:不要在头文件中使用全局声明或指令。在实现文件中随意使用它们。以下是Herb Sutter和Andrei Alexandrescu在 C++ Coding Standards (大胆强调是我的):

总结

名称空间使用是为了您的方便,而不是您强加给其他人:不要在include指令之前编写using声明或using指令。

推论:在头文件中,不要使用指令或声明来编写命名空间级别;相反,要显式地限定所有名称。(第二条规则从第一条开始,因为头永远不知道其他头包含的内容可能会出现在它们后面。)

讨论

简而言之:在include指令之后,您可以并且应该在实现文件中自由地使用声明和指令来使用名称空间,并且感觉良好。 尽管重复的断言与此相反,使用声明和指令的名称空间并不邪恶,也不会破坏名称空间的目的。相反,它们使名称空间可用 .

不应该在全局范围内使用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 ……) 因为它较短,并且能够处理用户定义的浮点类型(通过依赖于参数的查找)。

不要在全球范围内使用它

只有当 全球使用 . 因为:

• 您使正在编程的名称空间混乱。
• 当您使用多个标识符时,读者将很难看到特定标识符的来源。 using namespace xyz .
• 无论什么是真的 其他 对于最常读源代码的人来说,源代码的读者甚至更真实:你自己。一两年后再来看看……
• 如果你只谈论 using namespace std 你可能不知道你拿走的所有东西——当你添加另一个的时候 #include 或者移动到一个新的C++版本中,你可能会发现你不知道的名字冲突。

你可以在本地使用

继续在本地(几乎)免费使用它。当然,这会阻止你重复 std:: --重复也是不好的。

本地使用的成语

在C++ 03中有一个成语——样板代码——用于实现一个 swap 为您的课程提供功能。有人建议你使用本地的 使用命名空间标准 --或者至少 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::掉期 被更改以查找潜在的超负荷并选择它。

如果导入正确的头文件,则会突然出现以下名称: hex ,请 left , plus 或 count 在您的全球范围内。如果你没有意识到 std:: 包含这些名称。如果您还尝试在本地使用这些名称,可能会导致相当多的混淆。

如果所有标准的东西都在自己的名称空间中,那么就不必担心与代码或其他库的名称冲突。

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

经验丰富的程序员还试图避免对源文件中的名称进行完全限定。造成这种情况的一个次要原因是,在足够少的代码时编写更多的代码并不优雅。 除非有充分的理由 . 这主要是因为关闭了依赖于参数的查找(ADL)。

这些是什么 好理由 ?有时程序员明确地想关闭ADL,而有时他们想消除歧义。

所以下面是可以的:

1. 在函数实现中使用指令和声明的函数级
2. 在源文件中使用声明的源文件级别
3. (有时)使用指令的源文件级别

另一个原因是惊喜。

如果我看见 cout << blah 而不是 std::cout << blah

我想这是什么 cout ?是正常的吗 咳嗽 ?有什么特别的吗?

我同意它不应该在全球范围内使用,但是在本地使用并不那么邪恶,就像在 namespace . 下面是一个例子 “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 namespace Her_lib )

我也认为这是一种不好的做法。为什么?就在一天,我认为名称空间的功能是划分东西,所以我不应该把所有东西都扔到一个全局包中。 但是,如果我经常使用“cout”和“cin”,我会写: using std::cout; using std::cin; 在cpp文件中(从不在头文件中传播 #include )我想没有一个理智的人会说出一条小溪的名字 cout 或 cin . ;)

很高兴看到代码并知道它的作用。如果我看见 std::cout 我知道这就是 cout 流 std 图书馆。如果我看见 咳嗽 那我就不知道了。它 能够 成为 咳嗽 溪流 标准 图书馆。或者有一个 int cout = 0; 在同一个函数中高出十行。或A static 变量名 咳嗽 在那个文件里。它可以是任何东西。

现在以一百万行代码为基础,这并不是特别大,你在搜索一个bug,这意味着你知道在这一百万行中有一行代码不能做它应该做的。 cout << 1; 可以阅读 static int 命名 咳嗽 ,将其向左移动一位,然后丢弃结果。找虫子,我得检查一下。你知道我是多么的喜欢看吗 性病:咳嗽 ?

如果你是一名教师,而且从不需要为生活而写和维护任何代码,那么这是其中一个看起来非常好的主意。我喜欢在以下地方看到代码:(1)我知道它做什么;(2)我相信编写代码的人知道它做什么。

一切都是为了管理复杂性。使用名称空间将拉入您不想要的东西,因此可能会使调试更加困难(我说可能)。到处使用std::很难阅读(更多的文本和所有这些)。

马的课程-管理你的复杂性如何你能最好地和感觉能力。

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

2. 如果你只使用cout,没有人会感到困惑。但是当有很多名称空间在你周围飞来飞去,你看到这个类,而你不确定它在做什么时,让名称空间显式作为一种注释。您可以第一眼看到,‘哦,这是一个文件系统操作’或者‘这是在做网络工作’。

同时使用多个名称空间显然是造成灾难的原因,但只使用名称空间 std 而且只有命名空间 性病 在我看来没什么大不了的,因为重新定义只能由你自己的代码来实现…

所以只要把它们当作保留名称,比如“int”或“class”,就可以了。

人们应该停止对这件事如此无礼。你的老师一直都很好。只需使用一个名称空间;这是首先使用名称空间的全部要点。不能同时使用多个。除非是你自己的。因此,重新定义也不会发生。

考虑

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


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

class stringstream {  // uh oh
};

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

这并不可怕,但如果不在头文件或全局命名空间中使用它,就可以省去自己的麻烦。在非常有限的范围内完成这项工作可能没问题,但我从来没有遇到过输入额外的5个字符来说明我的函数来自何处的问题。

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

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

澄清问题的具体例子。假设您有两个库,foo和bar,每个库都有自己的名称空间:

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

namespace bar {
    ...
}

现在假设您在自己的程序中同时使用foo和bar,如下所示:

using namespace foo;
using namespace bar;

void main() {
    a(42);
}

在这一点上,一切都很好。当你运行你的程序时,它会“做一些事情”。但后来你更新了这个工具栏,让我们假设它已经改变为:

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)
}

所以你需要做一些维护来澄清你的意思是什么(即 foo::a )这可能是不可取的,但幸运的是,这很容易 foo:: 在所有呼叫之前 a 编译器标记为不明确)。

但是想象一下另一种情况,酒吧变成了这样:

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

此时你的电话 a(42) 突然与 bar::a 而不是 福奥:A 而不是做“某件事”,而是做“完全不同的事”。没有编译器警告或任何内容。你的程序只是静静地开始做一些与以前完全不同的事情。

当您使用一个名称空间时,您会冒这样的风险,这就是为什么人们不愿意使用名称空间的原因。名称空间中的内容越多,冲突的风险就越大,因此使用名称空间std(由于该名称空间中的内容数量多)的人可能比使用其他名称空间更不舒服。

最终,这是可写性与可靠性/可维护性之间的权衡。可读性也可以考虑,但我可以看到这两种情况的论据。通常我会说可靠性和可维护性更重要,但在这种情况下,您将经常为相当罕见的可靠性/可维护性影响支付可写性成本。“最佳”权衡将决定你的项目和你的优先顺序。

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

使用名称空间std的一个示例由于计数的模糊性而引发编译错误,这也是算法库中的一个函数。

#include <iostream>

using namespace std;

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

我认为在任何情况下都不一定是不好的做法,但使用时要小心。如果您正在编写一个库,那么您可能应该使用带有名称空间的范围解析操作符来防止您的库与其他库发生冲突。对于应用程序级代码,我看不出它有什么问题。

它不会使您的软件或项目性能变差,在源代码开头包含名称空间也不错。包括 using namespace std 根据您的需求和开发软件或项目的方式,说明会有所不同。

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

如本文所述 page :

使用命名空间std的语句通常被认为是错误的 实践。此语句的另一种选择是指定 使用范围运算符(::)将标识符所属的命名空间 每次我们声明一个类型时。

看到 this opinion :

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

有人说把 使用命名空间标准 在源文件中,因为您从该名称空间调用了所有函数和变量。如果要定义与中包含的另一个函数同名的新函数, 命名空间性病 您将重载函数,它可能由于编译或执行而产生问题。它不会像您期望的那样编译或执行。

如本文所述 页 :

尽管语句避免了在任何时候 我们希望访问在std名称空间中定义的类或类型, 将整个std命名空间导入当前命名空间 程序的。让我们举几个例子来理解为什么 可能不是件好事

…

现在在开发的后期,我们希望使用 在某个名为__foo__的库中自定义实现的cout(用于 实例)

…

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

“为什么使用命名空间STD?”被认为是C++中的一个坏习惯吗?

我换一种说法:为什么有些人认为输入5个额外的字符很麻烦?

例如,编写一个数字软件,当“vector”是问题域最重要的概念之一时,为什么还要考虑通过将一般的“std::vector”缩减为“vector”来污染全局命名空间?

这取决于它的位置。如果它是一个公共头,那么您将通过将其合并到全局名称空间来减小名称空间的值。记住,这可能是一种使模块全局化的好方法。

这是一种不好的做法,通常被称为全球名称空间污染。当多个命名空间具有相同的带签名的函数名时,可能会出现问题,那么编译器将不明确地决定要调用哪个命名空间,当您使用类似的函数调用指定命名空间时,可以避免所有这些问题。 std::cout . 希望这有帮助。:)

我同意其他人的看法,这是在要求名字冲突,模棱两可,然后事实是它不太明确。当我看到 using ,我个人的偏好是限制它。我也会强烈考虑其他人指出的:

如果您想找到一个可能是一个相当常见的名称的函数名,但只想在 std 名称空间(或相反的“You want to change all calls that are not in namespace 性病 ,命名空间 X 那么你打算怎么做呢?你可以写一个程序来完成它,但是花时间在你的项目本身上,而不是写一个程序来维护你的项目,难道不是更好吗?

我个人并不介意 std:: 前缀。我更喜欢它的外观而不是没有它。我不知道这是不是因为它是明确的并且对我说“这不是我的代码…我正在使用标准库“或者如果它是其他东西,但我认为它看起来更好。这可能是奇怪的,因为我最近才进入C++(使用和仍然做C和其他语言更长的时间,C是我最喜欢的语言的所有时间,就在大会)。

还有另外一件事,尽管它与上述以及其他人指出的有些关系。虽然这可能是不好的练习,但我有时会保留 std::name 用于标准库版本和程序特定实现的名称。是的,这确实会咬你,咬你一口,但归根结底,我从零开始这个项目,我是唯一的程序员。示例:I过载 std::string 并称之为 string . 我有一些有用的补充。我之所以这样做,部分是因为我的C和Unix(+Linux)倾向于使用小写名称。

除此之外,还可以有名称空间别名。下面是一个例子,说明它在哪些地方有用,而这些地方可能没有被提及。我使用C++ 11标准,特别是用LIbSTDC++ ++。嗯,它还没有完成 std::regex 支持。当然,它会编译,但它会抛出一个异常,这是程序员端的一个错误。但它缺乏实施。我就是这样解决的。安装Boost的Regex,连接它。然后,我执行以下操作,以便当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的regex成为 性病 . 我这样做是为了将来的整合,我再次承认,这完全是一种偏见——我不认为它像 boost::regex:: ... 这对我来说确实是另一回事。在C++中有很多东西我还没有完全在外观和方法中接受(另一个例子:可变模板与var ARGs)[虽然我承认可变模板是非常有用的!)即使是我接受的那些人也很困难,我仍然和他们有问题。

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

为了回答你的问题,我实际上是这样看的:很多程序员(不是所有人)都调用名称空间std。因此,人们应该养成不使用与名称空间std中名称相同的东西的习惯。这是非常理所当然的,但与可能的连贯词和假名的数量相比,这是不太可能的。这可以严格地说出来。

我是说真的…说“不要依赖这个存在”,就是让你相信它不存在。您经常会遇到借用代码片段并不断修复它们的问题。只要保持你的用户定义和借来的东西在有限的范围内,因为他们应该,并非常节省与全球(老实说,全球应该几乎总是最后的手段,目的是“编译现在,健全以后”)。我真的认为这是老师的坏建议,因为使用std对“cout”和“std::cout”都有效,但不使用std只对“std::cout”有效。您并不总是幸运地编写自己的代码。

注意:在您真正了解编译器的工作原理之前,不要过于关注效率问题。有了一点编码的经验,在你意识到好的代码能够概括为简单的东西之前,你不必对它们了解那么多。每一点都很简单,就好像你用C语言写了整件事一样。好的代码只是它需要的那么复杂而已。

根据我的经验,如果你有多个图书馆,比如, cout 但是为了另一个目的你可能会用错 咳嗽 .

例如,如果我输入, using namespace std; 和 using namespace otherlib; 而类型只是不能(恰好在两者中),而不是 std::cout (或) 'otherlib::cout' )你可能会用错了,而且会出错,使用起来更有效更高效。 性病:咳嗽 .