c+标头中的“使用命名空间”

Question

c+标头中的“使用命名空间”

在我们所有的c+课程中，所有的老师总是把using namespace std;就在#include在他们的.h档案。这在我看来是很危险的，因为通过在另一个程序中包含那个头，我将把名称空间导入到我的程序中，也许没有意识到、有意或者想要它(头包含可能是非常深嵌套的)。

所以我的问题是双重的：我说的对吗？using namespace不应在头文件中使用，和/或是否有某种方法可以撤消它，例如：

//header.husing namespace std {...}

还有一个类似的问题：头文件是否应该#include它对应的所有标头.cpp文件需要的文件，只需要那些标头定义所需的文件，并且让.cpp档案#include其余的，或者没有，并声明它所需要的一切extern?
这个问题背后的理由和上面的一样：我不想在包括.h档案。

而且，如果我是对的，这是一个常见的错误吗？我的意思是在现实世界的编程和“真实的”项目中。

谢谢。

Answer 1

你绝对不应该用using namespace在Header中，由于您所说的原因，它可以意外地更改包含该标头的任何其他文件中的代码的含义。没有办法撤销using namespace这也是它如此危险的另一个原因。我通常只是用grep或者是为了确保using namespace不是在标题中被调用，而不是尝试任何更复杂的东西。可能静态代码检查器也会标记这一点。标头应该只包含它需要编译的头。执行此操作的一个简单方法是始终将每个源文件的自己的头作为第一件事，放在任何其他头之前。如果头文件不自载，源文件将无法编译。在某些情况下，例如引用库中的实现细节类，可以使用前向声明而不是#include因为您完全控制了这种前向声明类的定义。我不确定我是否会说它是普通的，但它肯定会偶尔出现，通常是由新程序员编写的，他们不知道这会带来什么负面后果。通常，只要一点关于风险的教育就能解决任何问题，因为解决起来相对简单。

Answer 2

当在标题中包含标题时，您需要小心。在大型项目中，它可以创建一个非常复杂的依赖链，触发比实际需要的更大/更长的重建。检查这篇文章和它的后续行动更多地了解良好的物理结构在C+项目中的重要性。只有在绝对需要时(无论何时需要类的完整定义)，才应该在标头中包含头，并在可能的地方使用前向声明(当需要类是指针或引用时)。至于名称空间，我倾向于在头文件中使用显式命名空间范围，并且只将using namespace在我的CPP文件里。