아놔, 야심차게 삽질하고 있는 프로젝트가 있고 거기에 사용할 라이브러리를 만드는게 내 임무다. 다양한 클래스 타입을 잘 소화해야만 하는 요청을 충족하기 위해 - 간단하게는 막고 품어도 상관 없지만 - 템플릿을 사용하였다. 코드량을 줄이려고 사용하고는 있는데 모든 method를 정의하려면 - 코드를 보기 쉽게 하기 위해 선언과 정의를 분리하였다 - 위에 template 어찌고를 써야하고, argument가 내부 정의형이라면 쒧!스럽게도 하나하나에 범위를 넣어줘야하고... 아무튼 그냥 막고 품는 것보다 더 많은 코드를 요하고 있다. 그러나 이것은 다른 여러 형태로 분기할 때마다 단순히 typedef CMyTemplate<my_type> CMyType; 이라고만 하면 다시 코딩할 필요가 없고 - 그러나 바이너리는 그만큼이 만들어지는 - 논리상 오류가 발생하면 하나만 고쳐도 모든 실제 클래스가 적용 받기 때문에 관리도 용의한 편이다.
그러나 참을 수 없는 건... DEBUG! 컴파일 에러가 떨어질 때마다 오류가 어디에서 났는지부터 찾기 힘들다. 템플릿에 적용한 타입을 모두 풀어서 보여주기 때문에 에러메시지가 한 없이 길기 때문이다. 더욱 더 디버깅에 힘든 것은, 사용하지 않은 method는 바이너리로 생성하지 않기 때문에 - 당연한거다 - 단위 테스트할 때 오류가 있는 method를 사용해보지 않았다면, 통합 테스트에 반드시 오류가 발생한다. 어김 없다.
... 템플릿 프로그래밍 그늘이지만, 그래도 템플릿이 내 업무량을 상당히 감소해준 것만은 부인할 수 없다.
그러나 참을 수 없는 건... DEBUG! 컴파일 에러가 떨어질 때마다 오류가 어디에서 났는지부터 찾기 힘들다. 템플릿에 적용한 타입을 모두 풀어서 보여주기 때문에 에러메시지가 한 없이 길기 때문이다. 더욱 더 디버깅에 힘든 것은, 사용하지 않은 method는 바이너리로 생성하지 않기 때문에 - 당연한거다 - 단위 테스트할 때 오류가 있는 method를 사용해보지 않았다면, 통합 테스트에 반드시 오류가 발생한다. 어김 없다.
... 템플릿 프로그래밍 그늘이지만, 그래도 템플릿이 내 업무량을 상당히 감소해준 것만은 부인할 수 없다.
댓글
댓글 쓰기