10장 인스턴스화 4부 : 컴파일러가 템플릿 코드를 구현한 방식

Introduction

템플릿 코드가 번역 단위마다 인스턴스화 되는 문제(이게 왜 문제이냐면, 컴파일 후 링크 단계에서 단일 정의 원칙:ODR을 위배하므로 링크되지 않는다)를 해결하기 위한 대표적인 3가지 방법을 알아 보는 장이다.

Content

1. 일단 먹고 보는 인스턴스화 : Greedy Instantiation

책에는 근시안적 인스턴스화 라고 되어 있는데, .. 전체적인 그림을 보지 않고, 눈 앞에 보이면, 그냥 인스턴스화 한다는 말이다. 이렇게 진행하게 되면, 아마도 내 생각에는 컴파일러 제작자가 편할 것이다. 나중에 1개로 취합만 하면 되기 때문이다. (상대적인 편함이지, 기술이 없다는 것을 의미하지 않는다.)

이 기술에 대해서는 이야기가 나와 있지 않고, 링커가 1개의 인스턴스화만 남기고 모두 버린다고 한다.(공리)

이 방법의 단점은 1. 컴파일 시간이 길어지고, 2. 목적 파일(obj) 크기가 커지며, 3. 서로 다른 상태로 인스턴스화 된 obj 파일을 검사하지 않는다.

3번은 추가 설명이 더 필요한데, 링커 단계에서 1개의 인스턴스화를 빼고 모두 버리기 때문에, 디버깅으로 컴파일 된 템플릿 코드가 릴리즈로 컴파일 된 템플릿 코드에 씌워질 수 있다. (이 부분은 책 내용이 명확하게 나오지 않았기 때문에, 내가 추론한 것이다. 현재 번역하신 한정애 씨에게 질문을 올린 상태)

장점은 전통적인 소스 파일과 목적파일 관계를 유지 할 수 있다는 점이다. 이게 왜 장점인지는 책에 나와 있지 않지만, 추론해 보면 기존 컴파일러를 적은 비용으로 기능 구현 할 수 있기 때문인것 같다.(.. 이건 컴파일러 사용자에겐 이점이 아니잖아! )

2. 질의 인스턴스화 : 번역 전 원어가 무엇인지 모름

쉽게 생각해 템플릿 코드를 인스턴스화 할 때, "인스턴스화 해도 되? 안되?" 를 물어 보며 인스턴스화 하는 것이다. 인스턴스화가 된다면, DB에 저장해 두었다가, 다음에 질의가 있을 때 "있으니까 안되" 라고 명령 내릴 수 있다.

장점은 컴파일 타임이 1번 방식 보다 빠르다는 점이다. 단점은 DB를 관리해야 하며, DB까지 남겨 두어야 한다는 점이다. 복잡 미묘한 상황이 왔을 때, 이렇게 남긴 DB를 참조하여 해결하거나 1번 방식으로 문제를 해결 한다고 한다. .. 역시 이런건 컴파일러 제작자의 삶을 피곤하게 만들 것이다.

3. 반복된 인스턴스화 : 번역 전 원어가 무엇인지 모름

방법은 이러하다. 1. 템플릿 코드를 인스턴스화 하지 않고 컴파일 한다, 2. 목적 파일을 링크 한다. 3. 링크 할 때 인스턴스화가 없어서 발생된 문제일 경우, 이 때 인스턴스화 한다. 4. 그리곤 문제가 발생된 소스를 다시 컴파일 하며, 다 컴파일 될때까지 무제한 반복한다.

단점은 1. 템플릿 에러 메세지를 보기 위해선 링크 할 때까지 기다려야 한다. 2. 컴파일 시간이 무척 많이 든다. 3. 특정 정의가 있는 소스 코드 위치를 기억해 두어야 한다.

3번은 추가 정리가 필요할 듯 한데, 책에는 왜 이게 단점인지 나와 있지 않다. 아마도 에러 발생이 링크 할 때 발생 되기 때문에, 소스 코드 위치를 안알려 줘 그런것 같다.

그럼에도 몇가지 좋은 점이 있는데, 집중해서 읽는것 자체가 더 이상 싫다. 결론만 말하면, 처음 컴파일시 많은 시간이 걸리지만, 재컴파일 할 때는 훨씬 빨라진다고 한다.(내부적으로 기록해 두었다가 컴파일 할 필요가 없으면 안하는 것을 통해서..)

Digression

번역 전 원어가 무엇인지 모르는 것이 있다. 책에는 나오지 않았기 때문인데, 아는 사람 있으면 리플을 부탁 드립니다.