내 stdbool.h가 /usr/include에 없는 이유는 무엇입니까?

내 stdbool.h가 /usr/include에 없는 이유는 무엇입니까?

나는 표준 C 헤더 파일 /usr/include(예 stdio.h: stdlib.h, , string.hctype.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 버전에서 다음 버전으로 변경되어서는 안 됩니다. 그리고 당연히 버전 간에는 실질적인 차이가 없습니다. (*) 왜 이 하나는 컴파일러에 특정하고 다른 하나는 시스템 전체에 적용됩니까?

* - 좋아요, 저작권 표시와 C++에서 사용하기 위한 CPLUSPLUS 버전 기반의 일부 ifdef입니다.

답변1

결국 이는 표준이므로 한 GCC 버전에서 다음 버전으로 변경되어서는 안 됩니다.

아니요아니요표준. 표준은 당신이 쓸 수 있다는 것입니다

#include <stdbool.h>
번역 단위 내에서는 특정 사항에 영향을 미칩니다. 보장 없음언어표준의 관점에서헤더는 파일입니다. 말할 것도 없이 컴퓨터 파일 시스템의 특정 디렉터리에 고정된 콘텐츠가 포함된 파일입니다.

이러한 표준 헤더의 요점은 포함 시 제공되어야 한다고 언어 표준에 명시된 내용을 제공하기 위해 C/C++ 컴파일러에 적합한 모든 작업을 수행한다는 것입니다. (일반적으로) 필요한 선언과 매크로를 제공하기 위해 컴파일러에서 제공하는 내부 키워드, pragma, 매크로 및 내장 함수를 사용합니다. 물론 이것은 컴파일러마다 다릅니다.

이것이 여기서 저지르는 두 번째 실수입니다. GCC가 유일한 C/C++ 컴파일러라고 생각하는 것은 근시안적인 실수입니다. 아마도 많은 컴파일러가 있는 오래된 DOS 또는 Win32 프로그래밍 배경을 가진 사람들은매우아이디어에 익숙하다표준 헤더 파일은 컴파일러와 밀접하게 관련되어 있습니다.. 예를 들어 Watcom C/C++에서 표준 헤더를 가져와 Borland, Microsoft, IBM 또는 기타 C/C++ 컴파일러와 함께 사용할 수는 없습니다.

이것이 취해야 할 아이디어입니다.이것은 당신에게도 해당됩니다. 목적을 달성하기 위해 표준 헤더에서 수행해야 하는 작업은 GCC 버전마다 다를 수 있지만반품(예를 들어) clang과 GCC 사이에는 차이가 있을 수 있습니다. 유닉스와 리눅스 운영체제는아니요단일 컴파일러 단일 문화권.

실제로 float.h, limits.h, stdint.h, stddef.h, stdarg.h및 기타 여러 표준 헤더 파일이 이러한 컴파일러별 위치에 있다는 것을 알 수 있습니다. limits.h이는 컴파일러 관련 지식과 대상 플랫폼 관련 지식을 모두 포함하기 때문에 특히 혼란스러운 것입니다.

추가 읽기

답변2

UNIX 계열 시스템에서는 C 컴파일러(보통 gcc)와 C 표준 라이브러리(보통 glibc) 사이에 차이가 있습니다. 다른 많은 운영 체제와 달리 UNIX 계열 시스템의 C 표준 라이브러리는 기본 운영 체제 인터페이스 라이브러리 역할도 합니다.

C 표준을 읽는 것은 컴파일러와 플랫폼을 "구현"으로 함께 묶기 때문에 도움이 되지 않습니다.

일부 헤더 파일은 C 라이브러리 기능에 대한 인터페이스를 제공하는 것이 목적이기 때문에 C 라이브러리에 "속합니다". 이러한 헤더 파일은 C 라이브러리에 의해 설치되고 /usr/include에 배치됩니다.

다른 헤더는 컴파일러 기능을 설명하기 때문에 C 컴파일러에 "속합니다". 배포판은 일반적으로 여러 C 컴파일러를 지원하므로 컴파일러별 위치에 배치됩니다.

관련 정보