C++의 옛 기능 중 하나로, C++98에서 처음 추가된 이래 구현체가 하나 밖에 없었고(Comeau) 그마저도 표준화 위원회에서 제발 빼 달라고 사정 사정을 하여1) C++11에서 사라진 기능.
그 선조격인 C와 마찬가지로, C++는 전통적으로 매 소스 유닛을 컴파일할 때마다 그 소스가 참조하는 모든 "정의"(즉, 함수의 프로토타입이나 타입 정보들)를 매번 읽어 들어야 한다. 그러나 Cpp템플릿은 정의와 더불어 "선언"(즉, 함수의 몸체)도 매번 읽어서 컴파일해야 하는데, 이 때문에 복잡한 템플릿의 사용은 컴파일 시간을 뻥튀기하는 일등 공신으로 잘 알려져 있었다. export
는 이 문제를 템플릿의 정의와 선언을 분리할 수 있도록 하여 해결하려고 했던 시도이다. 즉 헤더 단에는 export
를 붙여 놓은 템플릿 정의만 써 놓고, 구현체가 이 정의를 다른 변환 유닛(translation unit)에 있는 실제 선언과 연결시킬 수 있는 가능성을 열어 놓은 것이다.
…여기까지면 참 좋았을텐데, C++ 템플릿의 설계라는 것이 분리 컴파일을 간단하게 가능하게 할 만큼 깔끔한 게 아니었다는 게 문제였다. 예를 들어서, 템플릿 인자를 뭘 주느냐에 따라서 같은 정의와 같은 선언을 가진 템플릿 코드라도 잘 컴파일되거나, 정의에서 오류가 나거나, 선언에서 오류가 나거나 할 수 있는데 이걸 분리 컴파일에서 흉내내려면 링크 과정이 매우 복잡해진다. 이런 문제를 줄이려면 템플릿 문법에 제약을 가해서 선언에서 오류가 날 가능성을 차단하거나 해야 하지만 표준에서는 여기에 대한 어떤 제약도 없다. 결국 이 기능을 구현하려면 C++ 템플릿(이 자체로도 사실 매우 큰 표준이다)의 모든 기능을 검토하면서 문제가 생길 가능성을 제거해야 한다는 얘기가 나오는데, 이게 설령 가능하다 하더라도 분리 컴파일으로 예상되는 장점인 컴파일 시간 감소가 가능한지조차 의심이 되는 상황이었다. 이 때문에 Comeau를 제외한 모든 컴파일러 벤더들이 구현을 포기했고, Comeau에서도 이 기능 구현만으로 웬만한 언어 구현보다 더 많은 노력을 쏟아 부었다고(…) 실토했을 정도.
결국 C++11에서는 이 기능이 사라지고, 나중을 대비하여 export
예약어를 사용하지 않은 채로 예약만 해 두는 쪽으로 표준이 변경되었다. 경사로세.