<c____> 头文件中声明的 C 函数是否保证在全局命名空间和 std 中？

Question

所以这是我一直想知道但一直不太确定的事情。所以这完全是出于好奇，而不是真正的问题。

据我了解，当您执行 #include <cstdlib> 之类的操作时，所有内容（当然宏除外）都在 std:: 命名空间中声明。我见过的每个实现都是通过执行以下操作来实现的：

#include <stdlib.h>
namespace std {
    using ::abort;
    // etc....
}

这当然具有全局命名空间和std 中的效果。这种行为是否得到保证？还是有可能实现可以将这些东西放在std 中，但不能放在全局命名空间中？我能想到的唯一方法是让你的 libstdc++ 实现每个 c 函数本身，将它们直接放在 std 中，而不是仅仅包括现有的 libc 标头（因为没有从命名空间中删除某些内容的机制）。这当然是付出了很多努力，却几乎没有任何好处。

我的问题的本质是，以下程序是否严格符合并保证工作？

#include <cstdio>
int main() {
    ::printf("hello world\n");
}

编辑：我找到的最接近的是这个（17.4.1.2p4）：

除非第 18 条至第 27、每个头cname的内容 应与 对应的头文件名.h，如 在 ISO/IEC 9899:1990 中规定 编程语言 C（第 7 条），或 ISO/IEC:1990 编程语言—C 修正案 1：C 完整性，（第 7 条）， 视情况而定，就好像通过包含一样。在 然而，C++ 标准库， 声明和定义 （定义为的名称除外 C) 中的宏在命名空间内 命名空间标准的范围（3.3.5）。

说实话，我可以用任何一种方式解释。 “每个标头 cname 的内容应与相应标头 name.h 的内容相同，如 ISO/IEC 9899:1990 Programming Languages C 中所述”告诉我它们可能在全局命名空间中是必需的，但是“在但是，C++ 标准库的声明和定义（名称除外） 在 C 中定义为宏）在命名空间 std 的命名空间范围（3.3.5）内。”表示它们在 std 中（但没有指定它们所在的任何其他范围）。

Answer 1

下面是 MSVC 团队 (http://blogs.msdn.com/vcblog/archive/2008/08/28/the-mallocator.aspx#8904359) 的 Stephan T. Lavavej 对情况的一个很好的概要（与标准所说的相比有些相关性）：

>，<cstddef>，<cstdlib>，和std::size_t等都应该使用！

我以前对此非常小心。 C++98 有一个美好的梦想，<cfoo> 将在命名空间 std 中声明所有内容，<foo.h> 将包含<cfoo>，然后使用 using-declarations 将所有内容拖入全局命名空间。 （这是 D.5 [depr.c.headers]。）

许多实现者都忽略了这一点（其中一些实现者对 C 标准库头文件几乎没有控制权）。因此，C++0x 已被更改以匹配现实。从 N2723 工作文件 http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf 开始，现在 <cfoo> 保证在命名空间 std 中声明所有内容，并且可能会或可能不会在全局命名空间中声明事物。 <foo.h> 则相反：它保证在全局命名空间中声明所有内容，并且可能会或可能不会在命名空间 std 中声明事物。

实际上，在 C++0x 中，包括 <cfoo> 并不能防止在全局命名空间中声明所有内容。这就是为什么我不再理会<cfoo>。

这是图书馆第 456 期，http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456。

（C++0x 仍然弃用 C 标准库中的头文件，这很有趣。）

我自己从不喜欢<cfoo> 标头，但发现我一直使用<foo.h>。现在我觉得我可以不再为我在这方面缺乏 C++“纯度”而焦虑了。

Answer 2

目前，没有。事实上，即使代码可以与我现在使用的每个编译器一起使用，它也确实不应该工作 - #includeing 其中一个 c* 标头只应该让您访问到命名空间 std 内的名称。

由于实现这一点非常痛苦（要做到这一点，基本上需要将整个 C 库复制为正确命名空间中的 C++ 库），在 C++ 0x 中，他们稍微改变了要求——你的代码现在是 允许工作，但（至少如果没有记错的话）它仍然不需要工作。

Answer 3

我不能代表标准，因为我没有读过它们，但是可以设想一个 C++ 环境，它不是建立在 C 环境之上的，或者 C 环境是底层 C++ API 之上的兼容层.在这种情况下，可能无法做出这些保证。如果禁止这样的实现成为合规实现，我会感到惊讶。