我之前编写过#include
Unix和Linux API标头的C ++代码,这些程序产生了预期的行为。也就是说,我不知道这是否可以依赖。当C ++程序使用时,C和C ++之间的不兼容可能导致有效的C头以意想不到的方式起作用。
可编译为C ++的代码可以可靠地使用Unix和Linux API头吗?
这是这些标题的作者的目标吗?或者这些标题只是有效的C?
这样做有什么已知的陷阱吗?
显然Unix和Linux发行版很多,我不希望得到一个答案来逐一解决每个发行版。我的期望是,相同的答案将适用于几乎所有的Unix和Linux发行版,异常将证明这一规则。如果这个假设是错误的,那么对此的解释也是一个有效的答案。
通过Unix标头我的意思是:
http://www.unix.org/version3/apis/headers.html
Linux标题我的意思是Linux发行版提供的标题通常是一个名为" linux-headers"允许程序与Linux内核交互。例如,这个Debian包:
https://packages.debian.org/wheezy/kernel/linux-headers-3.2.0-4-amd64
我意识到Unix链接只是一个规范,并且每个Linux发行版都不同但我再次怀疑为大多数发行版提出这个问题是合理的。如果那不对,请纠正我。
编辑我只是想引用用户空间程序使用的标头。
答案 0 :(得分:5)
标准标题如<stdio.h>
,<stdlib.h>
等在C ++标准的附录D中指定,其中指出:
这些已弃用的功能,其中已弃用定义为: 当前版本标准的规范性,但不保证 在未来的修订中成为标准的一部分。
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()
或其他任何内容。
但请注意,混合范式引发了各种各样的问题。仅举几例:
new
吗?dup2
来重定向cin
吗?main
执行之前),您可以安全地调用哪些POSIX函数?任何规范都没有解决这些问题及其他问题。答案取决于您的具体实施,并可能在不同版本之间进行更改。
说了这么多......几乎每个非平凡的C ++程序都依赖于某些C接口公开的特定于平台的功能。因此,如果您(a)知道发生了什(b)有合理的期望; (c)不要试图混合标准和平台特定的范例。
答案 1 :(得分:1)
1)是:&#34;标准标题&#34;是标准。无论平台如何,您都可以安全地使用它们。
2)是:您可以在相同的C ++翻译单元中将C标头(例如<stdio.h>
)与C ++标头(例如<iostream>
)混合使用。
3) NO :你不应在用户模式程序中使用 linux kernel 标头,反之亦然。
Linux内核头文件用于内核模式驱动程序,不用于&#34;普通&#34;用户空间应用程序。
以下是更多信息: