'#include "file2.c"는'gcc file1.c file2.c '와 (과) 다른가요?

Question

include 지시문보다 링커 명령을 선호하는 이유가 있습니까? 포함 파일을 별도로 다시 컴파일 할 계획이 없다면 을 사용해야합니까?

P. 문제가된다면 실제로 C++과 g ++에 관심이 있지만 gcc가 제네릭 컴파일러로 더 잘 인식 될 것이라고 생각했습니다.

Answer 1

링커를 선호 할 이유가 명령인가가 이상 지시

예

을 포함한다. 구현 파일 ( .c)을 여기 저기에 포함 시키면 심각한 문제가 발생합니다. 링커 오류 악명 높은 "기호 _MyFunc의 여러 정의"... ​​

(그런데, 그것은 또한 간주 나쁜 스타일/관행이 일반적으로 파일 만 포함하는 의미 헤더.)

Answer 2

만약을 만나 하나의 긴 C 파일을 가지고 싶다면 편집기를 사용하여 file2.c를 file1.c에 삽입 한 다음 file2.c를 삭제하십시오. 항상 함께한다면, 그럴 수도 있습니다. 이것을 위해 #include를 사용하는 것은 올바른 해결책이 아닙니다.

파일을 별도의 .c anc .cpp 파일로 분할하는 이유는 파일을 논리적으로 나머지 코드와 별도로 처리한다는 것입니다. 프로그램이 큰 경우 각 단위를 개별적으로 컴파일하는 것이 좋습니다.하지만 개별 파일로 분할하는 주된 이유는 각 코드 단위의 독립성을 보여주는 것입니다. 이렇게하면이 특정 파일에 영향을 미치는 다른 부분 (포함 된 헤더 참조)을 볼 수 있습니다. 클래스가 .cpp 파일에 대해 로컬 인 경우 클래스가 시스템의 다른 곳에서 사용되지 않는다는 것을 알고 있으므로 영향을받는 다른 구성 요소에 대해 걱정할 필요없이 해당 클래스의 내부를 안전하게 변경할 수 있습니다. 다른 한편으로, 모든 것이 하나의 큰 파일에 있다면, 무엇이 영향을 미치는지, 무엇이 변경하기에 안전한지를 추적하는 것은 매우 어렵습니다.

Answer 3

차이점은 다음과 같습니다. file1.c :

#include <stdio.h> 
static int foo = 37; 
int main() { printf("%d\n", foo); } 

file2.c는 :

static int foo = 42; 

이 두 사소한 모듈은 foo의 file2.c의 정의는 다음 사용되지 않는 경우에도, gcc file1.c file2.c으로 잘 컴파일합니다. static 식별자는 번역 단위 (일반적으로 모듈이라고하는 C의 버전)에서만 볼 수 있습니다.

당신이 #include "file2.c"file1.c, 당신은 효과적으로 두 파일은 이제 하나 개의 번역 단위되기 전에 식별자 충돌을 일으키는 원인이 file1.c에 file2.c를 삽입

.

원칙적으로 #include은 C 또는 C++ 소스 파일이 아닙니다. #include 헤더 만