항목 10 : export의 한계, 2부 : 상호작용, 유용성 문제, 지침들 ( 난이도 : 9 )

이번 항목은 항목 9에서 더 생각해 봐야 할 것 들을 이번 항목에서 다룬다. 이번 항목에선 "export의 한계"가 있음에도 불과하고, 왜 표준에 들어갔으며, 프로그래머에게 어떤 영향을 미치는지 알아 본다.

1 ) export가 현재 현태로 C++ 표준에 도입된 것은 언제이며, 처음으로 구현된 적은 언제인가?

템플릿에 관한 역사

1988년 10월, 비야네 스트롭스트룹이 초기 C++ 템플릿 설계를 발표

1990년, 마거릿 엘리스(Margaret Ellis)와 비야네 스트롭스트룹은 "The Annotated C++ Reference Manual"을 출판하였고, 거기에 템플릿의 전체 명세와 설명을 포함시켰다.

1994년, Stepanov가 STL을 위원회에 제시했다.

1995년, STL은 표준안으로 채용 되었다.

1996년, 템플릿의 export의 기능을 표준에 넣을지 말지 논쟁하게 된다.

1998년, 수 많은 논쟁 중, export가 표준에 채용된다.(2년간에 수많은 사람들이 넣을지 말지 논쟁을 벌였지만, "분리 컴파일" 모형을 어떤 형태로든 표준에 들어가지 않는다면, 표준이 불안전하다고 느꼈기 때문이다.)

1996년 부터 1998년까지 export를 표준에 넣을지 말지에 말은 많지만, 그 의도와 동기는 매우 좋았기 대문에, 누구도 비난 할수 없다고 책에선 ... 말한다.

우리는 표준에 채택이 되면 "그런게 있구나, 한번 써보고 좋은면 계속 써야지." 하는 입장이다 보니(표준에 채택되고니 말거니 실력이 딸리니, 모라 할 건덕지도 모르겠다..), 책에 있는 내용을 옮기자면,

export의 구현은 매우 힘들고, 난해한데, 그 이유가 다음과 같다.

1. export는 Koening lookup에 의존하는데, 현재 이 기능조차 제대로 조회하지 못하고 있는데, export를 구현하기 위해선여러 번역 단위(소스파일)를 거쳐야 하기 때문에 매우 힘들다.( 파서를 한번 만들어본 나로써는 .. 마음에 와 닫는다... )

2. 개념적으로 본다면, export를 위해서는 컴파일러가 여러 기호 테이블을 동시에 다뤄야 하는데, 이미 인스턴스화된 코드를 특정 테이블에 넣어 두고, 이 인스턴스화된 코드가 필요하게 될때, 테이블에 검색해서, "이미 있는가?"를 먼저 알아봐야 하는데, C++ 에서 이런 기호 테이블 하나를 다루는데도 복잡한데, 여러개의 기호 테이블을 다루어야 하는 것이 매우 힘들다.

: .. 기호 테이블이 무슨 것인지 모르겠으니, 어떻게 복잡한지 모르겠다.

2 ) export는 다른 C++ 언어 기능들의 의미를 어떻게 바꾸고, 그 상호 작용들을 설명하라.

1. 익명 이름 공간의 일부 함수들과 객체들이 export된 템플릿 안에 있는 경우, 번역 단위 전반에서 접근 및 호출할수 있게 된다. 아마도 이것은 Koening lookup이 번역 단위로 번지는거 같다. 이것은 다음 링크의 분석 2의 반대의 효과인것으로 생각 된다. (http://www.ikpil.com/670) 

2. 익명의 네임스페이스 안에 함수들을 넣어 둠으로써, 이름 충돌이나 소스코드 중복을 해결 할 수 있으나, export를 사용하게 되면, 이런 보호장치들이 풀리게 되어, 함수 이름을 복잡하게 질 수 밖에 없게 된다.

3. export를 이용하게 됨으로써, 단일 정의 규칙을 더 쉽게 위반 할수 있게 한다. "단일 정의 규칙" 이란? 무엇이든 한개만 정의되어야 한다는 규칙이다. 함수 또는 변수, 클래스 등의 명칭이 한개여야 한다는 규칙.

3 ) export가 프로그래머에게 어떻게 영향을 주는가?

1. 의미를 추측하기 힘들 프로그램을 작성할 가능성이 더 커진다. 예제가 없으니 잘 이해가 가지 않는다. export 시, 이름 조회 과정에서 여러 번역 단위들의 이름을 고려할 수 있기 때문이라고 한다. 2-1 답변 때문인가?

2. 프로그래머에게 도움이 되는 컴파일 타임 에러메세지가 매우 난해해 진다. 템플릿을 써보면 알겠지만, 지금도 난해한데, 더 난해해지만 정말 피 토한다.

3. export는 새로운 제약을 빌드환경에 가한다. 이 부분 잘 이해가 안간다. 단일 패스 링커 는 또 뭐지?

4 ) export가 가지고 있는 실질적이고, 잠재적인 이득은 무엇인가?

1. 빌드 속도를 개선 시킬 수 있다.

2. 매크로 번짐을 어느정도 억제 할 수 있다.(이 매크로 번짐 문제는 정말 귀찮게 한다.)

교훈

1. export 사용 하지 말것

2. .. 다시 사용하지 말것

3. 만약 쓴다 해도, 컴파일 타임을 줄여 줄 수 있거나, 분리컴파일을 할수 있다는 생각으로 사용 하지 말 것

총평

.. 요약하면, 현재 export를 사용하지 말라고 하는거 같다. MSVC2005 에서도 지원 못하는것으로 봐서, 앞으로도 구현하기 위해서 더 많은 시간이 필요 할 것이라고 보여진다. 아직 템플릿도 모든 컴파일러가 파싱하지 못하는 와중에 export 까지 할 수 있다는건 시기 상조 일듯 하다.

여기서도 전처리기 번짐 문제를 지적하는데, "번짐"이라는 표현이 참 마음에 든다. 매크로가 번졌다. .. 앞으로 많이 써 먹을 수 있을 듯 싶다. #define 은 나의 경우 거의 사용하지 않아도(.. 한번 당해보면 꺼리게 된다.), 이 경각심만은 남아 있다.

전체적으로 한번 더 봐야 겠다.