KPlay의 코딩 그리고 잡동사니

가령 A.c라는 소스파일과 B.c 그리고 D.c라는 3개의 소스파일이 있다고 해보자

A.c는 많은 함수들을 포함하고 있어서 B.c는 A.c의 함수들 중 8개의 함수들,

D.c는 A.c의 함수들 중 9개의 함수를 참조해야 한다고 가정하면

B.c에서는 exturn선언이 8개가 나와야하고 D.c에서는 9개의 exturn선언을 해줘야한다

무슨 함수가 필요한지 하나하나 확인해서 그걸 하나하나 exturn 선언을 하자니 여간 번거로운게아니다.

이럴 때, 많은 기능을 포함하고 있는 A.c를 헤더파일로 A.h로 바꿔버리면

B.c에서 이를 참조하려할때 #include "A.h"한줄만 쓰면 되고

D.c에서도 마찬가지로 한줄만 추가하면된다.

이때, 8개, 9개씩만 필요한데 나머지 4개, 3개도 가져와버리니 이거 비효율적인 메모리관리 아니냐고

생각할 수 있지만 exturn선언은 컴파일러에게 "단순 정보제공"을 하는것이기 때문에

아무리 많이 포함을해도 성능에 지장이 없기때문에 상관없다

여기까지 알고나면 그렇다면 그냥 모든 함수기능 하나의 헤더파일로 만들어버려서

모든 소스파일마다 그 헤더파일을 #include하면 편하지 않을까 생각할 수 있다.

그러나, 그렇게되면 헤더파일안의 기능들의 "관리"가 제대로 될 수 없다.

그래서 소스파일을 나누는 기준과, 헤더파일을 나누는 기준을 알아야한다.

예를들어

1. basicArith.c라는 소스파일에는 기본적인 사칙연산기능의 함수들이 들어있다.

2. areaArith.c 소스파일에는 넓이계산과 관련된 함수들이 들어있다(원의넓이라던가)

3. roundArith.c는 둘레계산과 관련된 함수들이 들어있다

이렇게 됐을때

2번 넓이계산과 3번 둘레계산에는 필수적으로 사칙연산이 필요함으로

1번 basicArith.c 소스파일의 기능들이 필수적이므로 이것의 exturn선언들을 담고있는 헤더파일을

2번과 3번에서 #include한다.

2번과 3번의 소스파일들도 특정한 기능들을 담고있기때문에 헤더파일들도 하나씩 만들어준다.

그 자체가 흐름을 구성하는 소스파일들은 헤더파일을 안만들어도 되겠지만

이렇게 특정한 기능들이 있어서 참조될거같은 소스파일들은 헤더파일들이 같이 존재한다 보통

그래서 정리하면

이런식이 된다

main.c같은 경우는 프로그램 내부에서 넓이계산과 둘레계산을 한다

따라서 2번과 3번의 헤더파일들을 #include한다

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

PI라는 이름의 매크로는 헤더파일에도, 소스파일에도 담길 수 있다

왜 여기서는 헤더파일에 넣어뒀을까?

파일 이름이 basicArith 즉 수학의 기본연산기능들이다.

기본연산을 하다보면 PI라는 상수도 당연히 필요할 때가 온다

앞에서 말했듯이 매크로의 정의는 파일단위로 유효하다

즉, D.c에서 매크로 PI를 정의했다고해서 A.c나 B.c에서 가져다 쓸 수 없고

각각의 소스파일에 정의해줘야한다.

필요로 할때마다 추가하면 똑같은 문장의 중복이된다.

또, 예를들어 PI값이 3.1415인데 3.0415인줄알고

각각의 소스파일에 PI는 3.0415라고 선언을 한 후 뒤늦게 틀린것을 알았다. 수정을해야하는데

여기서는 3개의 파일만 예시로 들었지만 실제로 큰 프로그램을 만들면 엄청난 수의 파일들을

하나하나 수정하는건 말이 안되는 작업이다.

그래서 다수의 소스파일에서 필요로하는 PI같은 상수는 헤더파일에 넣어두고 include하는것이다.

따라서 다수의 소스파일에서 참조가 될 수 있는 매크로의 정의도 헤더파일에 넣어두는것이 유용하다.

모든 매크로들을 다 헤더파일에 넣으라는게 아니다 모든 함수들을 다 헤더파일에 넣으라는게아니다.

정리하면, 헤더파일에는 다수의 소스파일에서 필요로하는 정의들을 묶어두는 용도로 헤더파일을 정의하는것이 좋다는것이다

이 글을 공유합시다

facebook twitter kakaoTalk kakaostory naver band