Introduction

이번 장은 템플릿이 언제 어떻게 실체화 되는지에 대해서 정리한 것이다. 이것을 알아야 하는 이유는 "템플릿의 가시화가 되지 않았기 때문에 컴파일이 되지 않는다" 라는 직관을 길르기 위해서이다. 총 5 파트의 정리가 있는데, 이번 파트에선 "주문형 인스턴스화" 만을 정리 한다.

Content

주문형 인스턴스화

우선 "인스턴스화 : instantiation" 이 어떤 단어인지 정의 해야 한다. 이 것은 실체화 라고 이해 하면 된다. C++ Template 에선 템플릿 코드가 실체화 되는 것을 인스턴스화 : instantiation 라고 한다. 여기서 말하는 주문형은, 프로그래머가 요구한 주문에 대해서 인스턴스화 되는 것을 뜻한다. - 원어가 어떻게 되어 있는지는 못찾겠다. : |

쉽게 말한다면, 클래스 템플릿에 템플릿 파라미터를 기입했을 때를 주문형 인스턴스화를 사용 한 것이다. 가장 리반적인 형태이다. 코드를 통해서 설명하는게 편하므로, 다음 코드를 봐보자.


지점 1 : 단순히 클래스 템플릿만 선언을 한 것이다. 지점 1 이후부터는 포인터나 레퍼런스만 만들 수 있다.

지점 2 : 선언한 클래스 템플릿이 인스턴스화가 되지 않았어도 포인터를 사용 할 수 있음을 타나내고 있다. 1번과 2번을 통해서 "전방 선언" 할 수 있다는 것을 알 수 있다.

지점 3 : 클래스 템플릿을 정의 하였다.

지점 4 : 지점 2와 마찬가지로 인스턴스나 정의가 없고, 선언만 있어도 충분히 컴파일을 할 수 있다.

지점 5 : 비로서 멤버 함수에 접금하므로, 클래스 템플릿에 대한 정의가 있어야 하며, 이 정의가 인스턴스화가 되어야지만 컴파일 된다. 인스턴스화를 하기 위해선 클래스 템플릿의 정의가 지점 5 시점에서 보여야 한다.

한가지 유의 해야 할 점은 "지점 5처럼, 항상 멤버 함수등(인스턴스가 필요한 지점)을 사용 했을 때만 인스턴스가 된 클래스가 필요한 것이 아니라는 점" 이다.

C++ 함수 오버로딩 해석을 할 때, 자동적으로 원할 때도 있고 원하지 않을 때도 있다.


지점 1과 지점 2에서 나타내듯이 candidate 함수는 오버로딩 되어 있다. 지점 3의 호출로 인해 지점 1함수 또는 지점 2함수가 호출 될지 컴파일러가 검사하기 위해서 ikpil 이라는 클래스가 인스턴스를 시킬 수 있다. 현재 ikpil 클래스 템플릿의 생성자에 대한 정의가 없으므로 컴파일이 되지 않을 수 있다.

테스트 결과 MSVC에선 잘 컴파일 되었으나, 표준 규칙을 잘 따르는 컴파일러에서 컴파일 해야한다면, 문제가 발생 될 수 있으므로, 기억해 두자.

Digression

인스턴스화에 대해서는 알고 있었으나, 오버로딩으로 인해 인스턴스화가 필요 할 수 도 있다는 것은 새롭게 알았다. 141 페이지에서 주문형 인스턴스화 설명할 때, 특수화도 주문형 인스턴스화 라고 설명이 있다. 하지만 이는 문맥상 뒷부분에 나와 있는 예제가 특수화에 대해서 없기에, 나는 생략했다. 부족한 정보가 있을 수 없으니, 책을 사라고 권한다.

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