C/C++의 가장 큰 특징 중 하나를 꼽으라면 preprocessor를 들 수 있다. 그리고 여기서 #define으로 정의되는 매크로는 참 오묘한 존재다. 매크로를 잘 쓰면 참 좋지만 너무 남용하면 난감할 때가 많다.

나는 매크로를 꽤 즐겨사용한다. MFC의 BEGIN_MESSAGE_MAP, RUNTIME_CLASS와 같은 매크로에 익숙해서 그런지 나만의 매크로를 만들어서 소위 언어 확장을 하는 경우가 있다. 내가 만든 매크로 중 좀 쓸만한 녀석은;;; C/C++의 빈약한 enum 기능을 확장한 것이 있다. C에서는 enum이 전역 레벨에서 정의가 되기 때문에 서로 중복된 이름을 쓸 수가 없고, scope같은 개념이 없어서 꽤 불편하다. 그래서 요런 것을 만들어 보았다.

내가 목표로한 macro enum은:
- enum_name::enum_element 와 같이 scope가 지원되도록
- int와 같은 크기이며 함수 인자 전달 시 오버헤드가 전혀 없도록
- switch - case에서 쓸 수 있도록 const 형으로
- String으로의 변환, String부터의 변환이 가능하도록
- Visual Studio의 인텔리 센스 기능이 가능하도록
- 마지막으로 다국어 지원을 위해 resource에서 스트링을 읽어올 수 있도록 (-_-)

다행히 위의 요구 사항을 만족시킬 수 있는 macro enum을 긴 삽질 끝에 만들었다. 이게 다 매크로의 힘이다. 대략 구현은 아래와 같은 아이디어에서 시작한다.

매크로를 잘 만들어 쓰고, 특히 가독성이 좋도록 최대한 신경을 쓰면, 코딩의 즐거움을 더할 수 있다. 그런데 순수 C코드를 분석하다보면 이놈의 매크로 때문에 짜증이 많이 난다. 다음은 GNU libc에서 사용되는 Doug Lea의 malloc 소스 중 일부분이다.

참 난감하다. 이런 경우 디버거를 통해 소스를 분석하는 나로서는 정말 난감하다. 그냥 디버거가 스킵해버리기 때문이다. 분석하려면 disassembly를 보는 수 밖에; 물론 저자의 의도는 이 매크로 함수는 large chunk를 unlink하니까 안에 구현은 신경쓰지마! 라는 의미로 했을 것이다. 그런데 난 저 과정을 분석해야한단 말이다.

그리고 각종 상수들도 매크로로 정의하는 것은 좋다. 그런데 그 상수가 또 다른 매크로를 사용하고, 그 매크로는 또 다른 매크로로부터 정의되고... 이렇게 되면 실제 디버거에서 이 값이 무엇인지 알려면 역시 난감하다. 디버거가 더 똑똑해지기를 기다려야하나.

위 소스에서 MIN_REQUEST 값을 알려면 직접 "계산"을 머리 속에서 하던가, disassembly를 보고 값을 찾아야한다. 저건 비교적 간단한 축에 속하고 malloc 소스에 보면 복잡한 상수가 많은데 디버깅 하다보면 이 값을 알고 싶을 때가 있는데 매번 불편함을 겪는다.

이해는 한다. 왜 이렇게 함수를 직접 매크로로 만들었고 이런 상수를 썼는지. 어떤 컴파일러는 최적화 기능이 빈약해서 함수 inlining이 잘 안되는 경우가 있을 것이다. 이러면 함수 호출에 따른 오버헤드가 유발되고 이런 것을 고려해 최대한 성능을 높이려고 이렇게 짰을 것이다.  그런데 최근의 컴파일러는 정말 똑똑하다. 사용자가 코딩할 때 저런 짜증나는 부분의 최적화는 신경 안 써도 컴파일러가 알아서 함수 호출을 제거해주고 inline화 해준다.

자기가 첨부터 코드를 짰으면 저런 매크로는 편할 것이다. 그런데 처음 소스 들여다보는 사람은 여간 불편한 것이 아니다. 매크로는 잘 쓰면 좋지만 마구 남용하면 시간 잡아먹기 딱 좋은 괴물이다. 혹시 모르지. 저자가 소스 분석을 어렵게 하기 위해 매크로라는 장벽을 쳤을 지도.



내가 생각하는 매크로 사용의 가이드 라인은:

1. 이름은 최대한 이상하게 (대문자라던가) 지어서 이것이 매크로임을 알려주자.
2. 컴파일러가 아주 구리지 않는 이상, 함수를 매크로로 만들지 말자. 템플릿도 있고 방법은 많다.
3. 가독성에 신경쓰자. 다른 사람이 나의 코드를 보고 쉽게 이해할 수 있도록.