☰

为什么我的 stdbool.h 不在 /usr/include 中？

tag-icon • tag-icon gcc c
为什么我的 stdbool.h 不在 /usr/include 中？

我习惯了标准 C 头文件/usr/include（例如stdio.h、stdlib.h、string.h等ctype.h）；然而——stdbool.h不是。现在，我知道它比其他的更新，只是 C99 的一部分。但是 - 我确实有，就在

/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdbool.h
/usr/lib/gcc/x86_64-linux-gnu/4.9/include/stdbool.h
/usr/lib/gcc/x86_64-linux-gnu/5/include/stdbool.h

每个 GCC 版本都有不同的位置。这是为什么？毕竟，它是一个标准 - 它不应该从一个 GCC 版本更改为下一个版本。而且，果然，版本之间没有真正的差异。 (*) 为什么这个是特定于编译器的，而其他是系统范围的？

* - 好吧，版权声明，以及一些基于 CPLUSPLUS 版本的 ifdef，用于与 C++ 一起使用时。

答案1

毕竟，它是一个标准 - 它不应该从一个 GCC 版本更改为下一个版本。

不，是不是一个标准。标准是你可以写

#include <stdbool.h>
在翻译单元中，它会影响某些事情。没有任何保证从语言标准来看标头是文件，更不用说它们是计算机上文件系统中特定目录中具有固定内容的文件。

此类标准头的全部要点是，它们会执行适合 C/C++ 编译器的任何操作，以提供语言标准规定在包含时应提供的内容。它们（通常）使用编译器提供的内部关键字、编译指示、宏和内在函数来提供所需的声明和宏。当然，这因编译器而异。

这是您在这里犯的第二个错误。认为 GCC 是唯一的 C/C++ 编译器是一种短视的错误。具有较旧 DOS 或 Win32 编程背景的人，那里可能有很多编译器，将会非常熟悉这个想法标准头文件与编译器密切相关。人们不能仅仅从（例如）Watcom C/C++ 中获取标准头文件并将其与 Borland、Microsoft、IBM 或任何 C/C++ 编译器一起使用。

这就是要采用的想法，因为这对你来说也是如此。虽然为了实现其目的需要在标准标头中完成的操作可能因 GCC 的一个版本而异，但它们还（比如说）clang 和 GCC 之间可能有所不同。 Unix 和 Linux 操作系统是不是单一编译器单一文化。

事实上，您会发现float.h、limits.h、stdint.h、stddef.h、stdarg.h和其他几个这样的标准头文件都驻留在这些编译器特定的位置。 limits.h这是一件特别混乱的事情，因为它既包含特定于编译器的知识，又包含特定于目标平台的知识。

进一步阅读

  • “4.1.2 标准标题”。 美国国家信息系统标准的基本原理 - 编程语言 - C。
  • 比亚恩·斯特鲁斯特鲁普 (2013)。 “标准库标题”。C++ 编程语言。第四版。艾迪生-韦斯利。国际标准书号 9780133522853。
  • 乔纳森·德博因·波拉德 (2012)。C/C++ 中的预定义宏可告诉您可用的语言功能。。常见答案。

答案2

在类 UNIX 系统上，C 编译器（通常为 gcc）和 C 标准库（通常为 glibc）之间存在区别。与许多其他操作系统不同，类 UNIX 系统上的 C 标准库也充当主要的操作系统接口库。

阅读 C 标准对您没有帮助，因为它们将编译器和平台作为“实现”结合在一起。

某些头文件“属于”C 库，因为它们的目的是提供 C 库功能的接口。这些头文件由 C 库安装并放入 /usr/include 中。

其他标头“属于”C 编译器，因为它们描述了编译器功能。由于发行版通常支持多个 C 编译器，因此这些编译器被放置在特定于编译器的位置。

相关内容