"export의 한계"라 표현한 것 보면, 무엇인가 기대한것에 미치지 못한다는 의미를 갖고 있다고 추측이 된다. 그런데 이 export 는 무슨 export 일까? 바로 템플릿의 export 이다. .. export 는 템플릿 말고, 몇개 더 있는거 같던데(라이브러리 만들때, 아니였나 만들어 본적이 없어서..), 이번 항목은 "템플릿의 export 함계"라고 말해도 좋을 듯 싶다.

질문으로 논쟁을 유도해 보자.

1 ) 템플릿의 "포함 모형"이 뜻하는 바는 무엇인가?

... 부스트의 hpp 같은 녀석들이랄까? 헤더 파일에 정의도 다 포함된 녀석들을 뜻한다. 대표적인 예로 stl 을 들 수 있겠다.


2 ) 템플릿의 "분리 모형"이 뜻하는 바는 무엇인가?

.h 와 .cpp 로 헤더파일과 정의 부분을 나누어서, 컴파일 하는 것과 같이, 템플릿의 헤더 부분과 정의 부분을 나눈 것을 뜻한다. 비야네서에 간략하게 소개 되었는데, http://kldp.org/node/47258 보면, 무슨 이야기인지 알 듯 싶다.


3 ) 다음에 대해 포함 모형이 가지는 주된 단점들은 무엇인가?

( a ) 보통 함수

( b ) 템플릿

.. 쉽게 생각해 보면, 함수 정의가 변경되면, 이 함수에 관련된 모든 것들을 재컴파일 해야 할 것이다. 다른 측면으로 본다면, 소스 코드 본문이 모두 노출되는 단점이 있다.


4 ) 3 )에 대해서 분리 모형은 어떻게 해결 하는가?

( a ) 보통 함수

.. 위에서 지적된 단점들이 다 보완된다. 소스 코드의 의존성이 낮아지고, 소스 코드 노출을 막을 수 있다.

( b ) 템플릿

export 키워드를 이용한다 해도, 분리 컴파일 되지 않는다. 또한 의존성을 없애주지도 않는다. MSVC2005 에서 테스트 해보니, export 는 아직 지원하지 않는 키워드라는 경고가 뜬다. (... )

현재까지 export 를 지원하는 컴파일러를 보면, export 는 의존성을 숨길뿐, 제거하지는 못한다고 한다. 그 이유는 컴파일러의 파싱 능력을 매우 많이 요구하게 되는데, 템플릿 특성상 사용 되어 질 때, 코드 인스턴스화 되는 시점에, 요구되어지는 타입들에 따라, 계속 생성되어야 하는건 변함이 없기 때문이다.


총평

우선 export 의 역사적 배경(?)부터 했다면, 좀 이해하기 편했을 듯(?) 했지만, 이것도 나름대로 재미있었다. 이번 항목의 결론은 export 에 "분리 모형" 이라는 기대를 걸지 말고 코딩하는게 더 편하다. 라고 할 수 있겠다. 다음 항목에서, 더 자세히 나오니 그때 가서 보도록 하자.



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