【问题标题】:should we move #include into namespace? [duplicate]我们应该将#include 移到命名空间吗? [复制]
【发布时间】:2012-03-29 15:57:40
【问题描述】:

可能重复:
Is it a good idea to wrap an #include in a namespace block?

// Method One
#ifndef XXX_H
#define XXX_H
#include <iostream>
#include "myhead.h"
namespace XXX
{
    /...
}
#endif

OR

// Method Two
namespace XXX
{
#ifndef XXX_H
#define XXX_H

    #include <iostream>
    #include "myhead.h"
    /...
#endif
}

当我们定义一个新的namespace XXX 时,我们是否应该将#include directive 移动到命名空间内?

谢谢

【问题讨论】:

标签: c++


【解决方案1】:

您必须在您的命名空间中包含 &lt;iostream&gt;。您将收到链接器错误。

我不建议在命名空间中包含任何标题。

唯一的例外是您的标头仅定义 extern "C" 函数(并且没有 C++ 函数或类),您通常可以将其包含在命名空间中而不会导致链接器问题。但这仍然可能不是一个好主意。

【讨论】:

  • 它不会导致缺少定义链接器错误,但很容易导致重复定义链接器错误,因为它并没有真正将定义放在命名空间中。
【解决方案2】:

这取决于你想要什么,因为两者并不等同。它们每个都有不同的含义。

如果您将它们包含在命名空间中,则标题将在命名空间内展开,这意味着标题中的所有名称都将在命名空间内声明/定义,在您的情况下为 XXX

因此,如果您愿意,可以这样做。如果你不想那样做,那么显然你不应该那样做。

请注意,如果您将 then 包含在命名空间中,您可能会收到链接器错误,因为您在 .cpp 文件中定义了那些符号,但在 XXX 命名空间中没有。所以声明将在命名空间XXX::ABC 中,而定义将在命名空间ABC 中。因此,由于这个原因,如果将 &lt;iostream&gt; 中的符号包含在 XXX 命名空间中,则会出现链接器错误。

【讨论】:

    【解决方案3】:

    不,您应该在命名空间之外执行#includes。否则,您将破坏您所包含的头文件中所有内容的名称。在您在上面发布的情况下,您将破坏标准库元素的名称;甚至不太可能成功构建。

    【讨论】:

      【解决方案4】:

      Afaik .. 第一个是更好的编码实践.. 再说一遍,这只是我 ..

      【讨论】:

      • 这没有提供问题的答案。要批评或要求作者澄清,请在其帖子下方发表评论。
      • @tune2fs:不同意:它并回答,只是不是一个很好的备份或有用的。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2014-06-07
      • 1970-01-01
      • 2011-05-16
      • 1970-01-01
      • 1970-01-01
      • 2015-11-12
      • 1970-01-01
      相关资源
      最近更新 更多