템플릿 코드는 디버깅 하기가 일반적인 코드보다 좀 더 까다롭다. 이 까다로움은 깊은 산속 옹달샘 만큼이나 찾기 어려운 문법 에러와 개념없이 작동되는 기능 때문에 생긴다.

깊은 산속 옹달샘 만큼이나 찾기 어려운 문법 에러
템플릿을 쓰다 보면, 템플릿 코드가 인스턴스가 되었을 때, 한편의 서정적이며 순수한 에러 메세지를 본 적이 있을 것이다. 기억을 더듬어 보니, 그런 에러가 다시 보고 싶다. 다음 코드를 컴파일 해 보자.

.. 코드는 16 줄 밖에 안되는 조그마한 프로그램이지만, 에러는 .. 다음과 같이 나올 것이다.

그래도 이건 좀 보기 편한 것이다. g++ 에서 컴파일 하면 .. 암호 해독 수준이기 때문이다. 이러한 문법 에러를 해석하는 것은 문제로까지 인식 되었고, 여러 선구자들이 에러메세지 해석 방법을 정리하기 시작했다. 다음 싸이트에서 그 정리를 볼 수 있다.

                http://www.bdsoft.com/tools/stlfilt.html

기억해 두자. 하지만 이런 해석방법보다는 더 간단한 에러 메세지를 출력하게 만드는게 좋겠다고 생각한  여러 선구자들은 The Boost Concept Check Library : BCCL 를 만들게 되었다. 간략히 설명하면, 더 얕은 인스턴스화를 하여 에러를 더 얕은 단계에서 출력하게 컴파일러의 에러를 유도하는 라이브러리 이다.

사용법

 8라인 때문에 에러메세지를 볼 수 있는데, 음.. 난 개인적으로 이것도 보기 힘들다고 생각한다. 그래도 처음보다는 좋은 편이기 때문에 위안을 삼자. 부수적으로 더 이야기 할 수 있는 건 이 BCCL 의 경우 지원하는 컴파일러가 있고 지원 못하는 컴파일러가 있기 때문에 뭐 알아서 쓰자. 나도 이런 식인거 밖에 모른다. 필요할 때 뒤져서 찾을 수 있게 이런게 있다고 기억을 꼭 해 두면 된다고 나는 생각 한다.

개념없이 작동 되는 기능
이 이야기는 일반 함수도 마찬가지라고 나는 생각한다. 왜냐하면 어차피 잘못된 개념을 사용 했을 때 그 구현을 직접 보기 전까지는 어떻게 작동되는지 알 수 없기 때문이다. 이걸 기계적으로 찾아 낼 수 없다. 이런 면에서 템플릿의 경우 훨씬 더 좋다. 왜냐하면 타입의 operator 연산자들에 일반관념이 적용될 수 있기 때문이다.

예를 들어 operator >, operator==, operator=, operator!= 등등 일반관념들로 무리없이 코딩 할 수 있기 때문이다.(.. 뭐 일반관념대로 안짜는게 더 큰 디버깅이 되겠지만.. )

그래도 조심해서 나쁠건 없기 때문에, 역시 선구자들이 "추격자 : tracer" 라는 개념의 도구를 만들었다. 이 추격자는 템플릿 코드 속에 녹아 들어가 직접 몸으로 템플릿을 체험하고 몇대 맞았는데 엄마한테 보고하는 시스템이라고 이해하면 좋을 듯 싶다.

책의 소스를 약간 손봐 요점만 간추려 소스코드를 옮겨 본다.

이 소스를 복사 하고, g++, msvc 등에서 비교하면 각 sort 함수의 성능을 추적 할 수 있다. ... 악!? 성능 체크를 위한 용도로도 쓰일 수 있다. 디테일 하게 상태를 기록하면, 이녀석이 개념이 있게 작동 되고 있는지, 더 확고하게 판단 할 수 있다. 원리는 static 멤버 변수로 전역 변수처럼 사용한다. 각 함수에서 이 멤버에 기록한다. 로 간추린다.

아참, 추적자에 어떠한 operator 나 함수들을 을 붙이고 뺌으로써 템플릿의 요구사항을 찾아 볼 수도 있다는 것을 알고 이해하고 있어야 한다. 위에선 operator< 만 사용했기에 정상 컴파일 되지만, operator< 부분을 주석처리 하거나 변형해서 다시 체크해 본다면 내가 무슨말 하는지 알 수 있을 것이다.

여담,
템플릿 코드를 만들때, 그 템플릿 코드를 검증 할 수 있는 예제 코드같은 것을 만들면 좋을 듯 싶다. 추적자:tracer 같은 녀석들 말이다..



  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 라이프코리아트위터 공유하기
  • shared
  • 카카오스토리 공유하기