【问题标题】:Is it a good idea to wrap an #include in a namespace block?在命名空间块中包装#include 是个好主意吗?
【发布时间】:2011-10-03 23:39:32
【问题描述】:

我有一个 C 头文件,它被编写为同时编译为 C 和 C++(它只使用公共子集中的功能,并使用 extern "C" 的东西)。

问题是,该标头在全局命名空间中声明了一些东西。出于通常的原因,我宁愿避免这种情况。我想过这样做:

namespace foo {
#include <foo.h>
}

这样做是个好主意吗?我有不包括编辑头文件的替代方法吗?

【问题讨论】:

  • 有趣的想法。但是,如果它是 C 代码,我会将其保留在原处:全局命名空间。

标签: c++ namespaces include


【解决方案1】:

不,这是个坏主意。使用 C++ 声明,可能会引入链接器错误,因为标识符在错误的命名空间中声明。使用 C 声明,它可以工作,但它可能会隐藏全局命名空间中标识符之间的冲突(我猜你试图避免这种冲突),直到链接时间;它并没有真的将标识符放在命名空间中。

更好的办法是将您自己的标识符放在命名空间中,避免在全局标识符中定义除 main 之外的任何内容。

【讨论】:

  • +1 我实际上遇到了这样的问题,因为某个开源项目决定做exactly this。结果是我不得不挖掘 numerous 项目和 std 标头来找出根本原因。我设法解决了它,但最终这只是另一个需要担心的移植问题。
  • 我感觉这不太对劲,但我说不出为什么。我很高兴我决定在这里问:)
  • 恭喜获得金牌 :)
  • 至少在汇编(代码生成)时间之前隐藏名称冲突的示例:coliru.stacked-crooked.com
【解决方案2】:

我在 1990 年代后期为 &lt;windows.h&gt; 做了这种“将其放置在名称空间中”。

虽然没有完全支持:它的原则是在我需要时为我接下来需要的任何东西添加支持。

完成这项工作的关键是检查包含了哪些 C 库头文件,并确保首先包含它们。它归结为 4 个这样的标题,IIRC。不过,微软对宏的喜爱让事情变得很困难。

所以它可以在实践中对 C 头文件(或 C++ 仅限于类 C 的子集)进行,但代价是为每个新版本的 wrappee 更新包装器,这是不切实际的和/或非常昂贵的。更不用说费力了。

总之,不,这不是一个好主意。 :-)

经验之谈。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-02-21
    • 1970-01-01
    • 2023-03-21
    • 2011-05-14
    • 2010-09-17
    • 1970-01-01
    相关资源
    最近更新 更多