我听说过使用名称空间std;这是不好的做法,我应该直接使用std::cout和std::cin。这是为什么?声明与std命名空间中的某个变量同名的变量是否有风险?


当前回答

命名空间是为了避免命名冲突。C++基于C,C在函数和变量名方面有很多问题,因为有时来自不同库的函数会发生冲突。因此,库开发人员开始在其函数前面加上库名,如下所示:

foo/foo.h:

void libfoo_foo_foo_h_open(); // the name can be weird then even this one!

C++引入了名称空间,以一种简单的方式解决了这个问题。

假设您有两个名为file和window的库,分别处理文件和窗口,代码如下:

#include <file.h>
#include <window.h>

using namespace file;
using namespace window;

void open() {
     ...
}

文件.h:

namespace file {
    void open(); // What!
}

window.h:

namespace window {
    void open(); // Oh no!
}

上面的代码肯定无法编译。

如果你不喜欢键入std::(只有5个字符),你可以一直这样做:(在头文件中不是个好主意)

using s = std;

如果您仍然想使用名称空间std;在您的源文件中,那么您正在引发这个问题,我必须问您“NAMESPACE的目的是什么?”。

其他回答

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

考虑

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


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

class stringstream {  // Uh oh
};

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

这并不可怕,但如果不在头文件或全局名称空间中使用它,您将省去麻烦。在非常有限的范围内执行它可能是正确的,但我从未遇到过键入额外的五个字符来澄清我的函数来自何处的问题。

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

using namespace foo;
using namespace bar;

一切都很好,你可以从Foo调用Blah(),从Bar调用Qux()。但有一天你升级到了Foo 2.0的新版本,它现在提供了一个名为Qux()的函数。现在出现了一个冲突:Foo 2.0和Bar都将Qux()导入到全局命名空间中。这将需要一些努力来解决,特别是如果函数参数恰好匹配。

如果您使用了foo::Blah()和bar::Qux(),那么引入foo::Qux()将是一个非事件。

#include <iostream>

using namespace std;

int main() {
  // There used to be
  // int left, right;
  // But not anymore

  if (left != right)
    std::cout << "Excuse me, WHAT?!\n";
}

那么,为什么?因为它引入了与常用变量名重叠的标识符,并允许编译此代码,将其解释为if(std::left!=std::right)。

PVS Studio可以使用V1058诊断程序找到这样的错误:https://godbolt.org/z/YZTwhp(谢谢Andrey Karpov!!)。

Ping cppcheck开发人员:您可能希望标记此项。这是一场灾难。

为了回答你的问题,我实际上是这样看的:很多程序员(不是所有人)都调用命名空间std。因此,人们应该养成习惯,不要使用与命名空间std中的名称冲突或使用相同名称的东西。这是一个很大的事实,但与严格来说可能出现的连贯单词和假名的数量相比,这并不是那么多。

我是说真的。。。说“不要依赖于这个存在”只是让你依赖于它不存在。您经常会遇到借用代码片段并不断修复它们的问题。只需将用户定义的和借用的内容保持在有限的范围内,并且非常节省全局变量(老实说,全局变量几乎永远是“现在编译,以后理智”的最后手段)。我真的认为这是你老师的坏建议,因为使用std对“cout”和“std::cout”都有效,但不使用std只对“std:”cout有效。你不会总是幸运地编写自己的代码。

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