Unix和Linux API头是否与C++兼容？

Question

我以前编写的C++代码是#includeUnix和Linux API头文件,这些程序产生了预期的行为.也就是说,我不知道这是否可以依赖.当C++程序使用时,C和C++之间的不兼容性可能会导致有效的C标头以意外的方式运行.

Unix和Linux API头文件是否可以被编译为C++的代码可靠地使用？

这是这些标题的作者的目标吗？或者这些标题只是有效的C？

这样做有什么已知的陷阱吗？

显然Unix和Linux发行版很多,我不希望得到一个答案来逐一解决每个发行版.我的期望是,相同的答案将适用于几乎所有的Unix和Linux发行版,异常将证明这一规则.如果这个假设是错误的,那么对它的解释也是一个有效的答案.

通过Unix标头我的意思是:

Linux头文件我的意思是Linux发行版提供的头文件通常是一个名为"linux-headers"的包,它允许程序与Linux内核交互.例如,这个Debian包:

我意识到Unix链接只是一个规范,并且每个Linux发行版都不同但我再次怀疑对大多数发行版提出这个问题是合理的.如果那不是真的那么纠正我.

编辑我只是指用户空间程序使用的标题.

Answer 1

C标准的附录D中规定了C标准标题,如<stdio.h>,<stdlib.h>等等,其中规定:

这些是已弃用的功能,其中不推荐使用的定义为:标准的当前版本的规范,但不保证在将来的版本中成为标准的一部分.

C标准头的非弃用C++版本名称类似<cstdio>,<cstdlib>等等,他们在技术上把自己定义成std(不是全球)命名空间.因此,为了100%符合C++规范的非弃用部分,您需要编写如下内容:

#include <cstdio>

int main() {
  std::printf("Hello, world!\n");
}

也就是说,据我所知,现有的实施实际上并没有迫使你这样做,而且我认为这种情况不太可能.因此在实践中,您可以安全地在C++中使用C标准头文件而不必担心.

此外,如果您在(例如)POSIX系统上,通常可以同样安全地使用C++中的POSIX功能.当然没有人会故意破坏这一点,因为用户会反抗.

然而,在混合范例时可以想到意外破损.如果平台和语言标准都提供某些功能,则应使用其中一个但不能同时使用两者.特别是,我不会将POSIX线程和同步机制与标准C++ 11线程和同步机制混合在一起,因为很容易想象优化器对后者了解太多并生成与前者不兼容的代码.

[更新,详细说明]

<unistd.h>我是关于平台相关功能的一个例子.它通常可以在C++中正常工作,并且库和编译器开发人员都不会无故分解它,因为这太烦人了.所以,尽管打电话getpid()或pipe()或什么的.

但请注意,混合范式引发了各种各样的问题.仅举几例:

任何规范都没有解决这些问题和其他问题.答案取决于您的具体实施,并可能在不同版本之间进行更改

说了这么多......几乎每个非平凡的C++程序都依赖于某些C接口暴露的特定于平台的功能.因此,如果您(a)知道"引擎盖下"发生了什么,那么您所描述的内容将在实践中正常运行; (b)有合理的期望; (c)不要试图混合标准和平台特定的范例.