可以将标准的纯 C 标头 #include 指令放在命名空间中吗？ [复制]

Question

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

我在全局命名空间 (::log) 中有一个类 log 的项目。

所以，很自然，在#include <cmath> 之后，每次我尝试实例化我的日志类的对象时，编译器都会给出一条错误消息，因为<cmath> 用许多三字母方法污染了全局命名空间，其中之一为对数函数log()。

所以有三种可能的解决方案，每一种都有其独特的丑陋副作用。

• 将日志类移动到它自己的命名空间，并始终使用它的完全限定名称访问它。我真的想避免这种情况，因为记录器应该尽可能方便使用。
• 编写一个mathwrapper.cpp 文件，这是项目中唯一包含<cmath> 的文件，并通过namespace math 中的包装器使所有必需的<cmath> 函数可用。我不想使用这种方法，因为我必须为每个所需的数学函数编写一个包装器，并且会增加额外的调用惩罚（由 -flto 编译器标志部分取消）
• 我目前正在考虑的解决方案：

替换

#include <cmath>

通过

namespace math {
#include "math.h"
}

然后通过math::log()计算对数函数。

我已经尝试过了，它确实可以按预期编译、链接和运行。但是，它确实有多个缺点：

• （显然）不可能使用 <cmath>，因为 <cmath> 代码通过其完全限定名称访问函数，并且不推荐在 C++ 中使用。
• 我有一种非常非常糟糕的感觉，就像我是gonna get attacked and eaten alive by raptors.

所以我的问题是：

• 是否有任何建议/约定/等禁止在命名空间中放置包含指令？

• 有什么问题吗

  • 不同的 C 标准库实现（我使用 glibc），
  • 不同的编译器（我使用 g++ 4.7，-std=c++11），
  • 链接？
• 您是否尝试过这样做？
• 是否有其他方法可以从全局命名空间中消除数学函数？

我在 stackoverflow 上发现了几个类似的问题，但大多数都是关于包含其他 C++ 头文件的，这显然是一个坏主意，而且那些没有对 C 库的链接行为做出矛盾的陈述。另外，将#include <math.h> 额外放在extern "C" {} 中是否有益？

编辑

所以我决定做可能其他人都在做的事情，并将我的所有代码放在项目命名空间中，并在包含 <cmath> 时使用它的完全限定名称访问记录器。

Answer 1

它也很丑陋，但我相信不会导致任何链接器问题。只需从<math.h>重新定义日志名称

 #define log math_log
 #include <math.h>
 #undef log

这可能会导致使用此日志的数学内联函数出现问题，但也许你会很幸运...

数学 log() 仍然可以访问，但这并不容易。在你想使用它的函数中，重复它的真实声明：

    int somefunc() {
        double log(double); // not sure if correct
        return log(1.1);
    }

Answer 2

Change your class's name. Not that big of a deal. ;-)

说真的，将名称放在与 any 标准标头中的名称冲突的全局名称空间中并不是一个好主意。 C++03 没有明确允许<cmath> 定义::log。但是由于在现有的<math.h> 之上定义<cmath> 的实用性（也许还有一些头文件的现有静态链接库，包括数学），因此实现长期不符合这一点。因此 C++11 认可了现有的做法，并允许 <cmath> 将所有内容转储到全局命名空间中。 C++11 还保留所有用于外部“C”链接的名称，以及所有用于 C++ 链接的函数签名，即使您不包含标头。但稍后会详细介绍。

因为在 C++ 中，任何标准头都可以定义来自任何其他标准头的名称（即允许它们相互包含），这意味着任何标准头都可以定义::log。所以不要使用它。

您关于不同实现的问题的答案是，即使您的方案一开始就可以工作（不能保证），在其他一些实现中可能会有一个您使用的标头（或希望将来在与您的日志类相同的 TU），其中包括 <cmath>，并且您没有给予 namespace math 处理。在我的脑海中，<random> 在我看来是一个候选人。它提供了一大堆连续的随机数分布，这些分布似乎可以通过数学函数实现。

我建议Log，但我喜欢大写的类名。部分原因是它们始终不同于标准类型和函数。

另一种可能性是像以前一样定义您的类并使用struct log 代替log。这不会与函数发生冲突，原因只有在您花费太多时间在 C 和 C++ 标准上时才会变得清晰（您只使用 log 作为 class 名称，而不是作为函数而不是带有“C”链接的名称，因此您不会侵犯保留名称。尽管所有的外观都相反，C++ 中的类名称仍然与其他名称处于平行宇宙中，就像struct 标签一样在 C) 中。

很遗憾，struct log 不是简单类型标识符，因此例如您不能使用struct log(VERY_VERBOSE, TO_FILE) 创建临时标识符。定义简单类型标识符：

typedef struct log Log;
Log(VERY_VERBOSE, TO_FILE); // unused temporary object

我在下面的评论中所说的示例，基于说明的示例用法。我认为这是有效的，但我不确定：

#include <iostream>
#include <cmath>
using std::log; // to enforce roughly what the compiler does anyway

enum Foo {
    foo, bar
};

std::ostream &log(Foo f) { return std::cout; }

int main() {
    log(foo) << log(10) << "\n";
}

Answer 3

不，您正在考虑的解决方案是不允许的。实际上，这意味着您正在更改头文件的含义。您正在更改其所有声明以声明不同命名的函数。

这些更改的声明与标准库函数的实际名称不匹配，因此，在链接时，任何标准库函数都不会解析对更改的声明声明的函数的调用，除非它们恰好被声明为 @987654322 @ 对于来自 C 标准库的名称，这是允许但不推荐的。

ISO/IEC 14882:2011 17.6.2.2/3 [using.headers] 适用于 C 标准库标头，因为它们是 C++ 标准库的一部分：

翻译单元应仅在任何外部声明或定义[*]之外包含标头，并且应在该翻译单元中第一次引用该标头中声明的任何实体之前在词法上包含标头。

[*] 将包含命名空间定义。

Answer 4

为什么不将日志类放在它自己的命名空间中并使用typedef namespace::log logger; 以更方便的方式避免名称冲突？