항목 31 : 이상한 코드 ( 난이도 : 4 )

이번 항목에서 말하고자 하는 것을 정확히 겪어 본 터라, 책의 예제는 생략하고, 경험담만 쓰려고 한다. 이번 항목은 #define 의 단점을 정확히 지적을 한다.

경험 1.

졸업 작품 만드는 중 KGCA15기 동기인 강일이형이 "도저히 디버깅을 할 수가 없는데, 좀 봐봐" 라고 하면서 코드를 보여 줬다. 이상이 없는 코드인데, 컴파일이 되지 않는 것이 문제점이 였다.

에러 메세지를 봐도, "이 문구의 에러가 아닌데 왜 이러는거야!" 라고 속으로 생각하다가, 혹시나 하고, 같은 이름의 것들이 있나 찾아 보게 되었다.

.. 그 순간, 아!! 아!! 를 연발하게 되었는데, 바로 #define 으로 정의된 이름을 함수명과 같기 때문 이였다. 전처리기에 의해서 함수명도 #define 정의된 이름으로 변경되면서, 생뚱맞은 코드로 변화된 것이였다.

경험 2.

졸업 작품 만드는 중 KGCA 15기 동기인 인찬이형이 "익필아, 이것좀 봐봐 신기하게 컴파일이 안된다" 라고 하면서 코드를 보여줬다. 아무리 봐도 전혀 이상 없는 코드였다.

함수명이 Load 였고, 클래스 멤버 함수였는데, '상수 표현식이 올수 없는 자리 입니다' 다 였나? 컴파일 오류를 벹어내는 것이였다. 혹시나 하고 숨겨진 문자가 있는지 다 지워보고 다시 써봐도 마찬가지였다.

그러던 중, Load 라는 부분이 보라색(#define 정의된 것은 보라색으로 보인다)으로 보이는 것이 아닌가?(Assist 사용 중이였으므로) .. 혹시 이것도!? 라는 생각에 Load2로 바꾸니깐 잘 된다. .. 그렇다 Load가 #define 정의된 것이였다.

경험 3.

자꾸 함수 호출이 쌩둥맞은게 되는게 아닌가? 함수는 DX로 텍스쳐를 로드하는 함수였다. 자꾸 이상한 함수가 호출 되길래 따라가 보니 #define 정의된 것이였다. 유니코드일 땐 뒤에 W가 붙은 함수가 호출되고 멀티바이트일 땐 A가 붙은 함수가 호출 되는 식으로 되어 있었다.

프로젝트는 유니코드 기반 작업이니, 상수 문자열을 사용 할 때 L"문자열", 로 인자를 전달해야 했었다.

총평

이런 것들 때문에, 나는 #define 을 거의 안쓴다. 쓸 수 밖에 없을 때도 있긴 한데, 그럴 땐, 절대 앞에 _ 를 붙이지 않는다 거나, 일반적인 이름의 사용을 피한다거나, 뒤에 __ 를 깔아 둔다.

.. 사실 생각해 보면, 난 #define 문제점을 겪은 후, 스콧 마이어스나, 허브 셔터의 말들이 생각이 나서 문제를 쉽게 찾을 수 있었다. 형들 고마워~