C++11 Type Traits. 라이브러리가 프로그래머의 제어에서 벗어나다

by Lyn posted Dec 30, 2015
?

단축키

Prev이전 문서

Next다음 문서

ESC닫기

크게 작게 위로 아래로 댓글로 가기 인쇄

C++ 은 C에서 유래한 오래된 언어 답게 가능한 한 최소한의 라이브러리만 가지고 있던 시절이 있었습니다. 

하지만 시대의 흐름은 거스를 수 없었고, STL이 추가 된 이후 200년대 이후 TR1을 시작으로 매우 많은 라이브러리들이 추가 되었습니다.

 

이 많은 라이브러리들은 모두 (당연하게도) 모두 C++로 만들어 져 있었으며 template 을 상당히 예전부터 가지고 있던 언어 답게 매우 많은 라이브러리가 template 기반으로 되어 있었고 template 의 특성상 라이브러리의 소스가 모두 공개될 수 밖에 없기 때문에 별다른 작업이 없이도 C++ 프로그래머들은 표준 라이브러리의 소스를 마음껏 볼 수 있었습니다(의외로 특정 언어의 라이브러리가 그 언어로 다 만들어진 경우가 드뭅니다)

 

덕분에 대체 tuple 의 소스는 어떻게 구현되어 있을까 궁금해서 열어봤다가, 2개부터 N개까지의 tuple 이 전부 따로 구현되어 있는 것을 보고 매우 실망했던 (T.T) 가슴아픈 기억도 있는데, C++ 표준위원회는 이러한 특정 라이브러리를 더 깔끔하게 만들기 위해 새 문법이 필요하다면 컴파일러 개발사들의 구현 가능여부 (....) 따위는 고려하지 않고 새 문법을 추가하였고(tuple 을 구현하기 위해 추가된 variadic template 라던가... 물론 이것도 고수들은 나름대로 다른곳에 쓸 방도를 찾아 내더군요. 그러라고 만들어준게 아닌 template 으로 metaprogramming을 한 것 처럼) 결국 영원히 추가되지 않을 듯 한 export 키워드라는 흑역사도 만들어 내었습니다.

 

하지만 C++11에서 Type Traits가 추가되면서 사정이 좀 달라지는데, 당시까지의 C++ 문법으로는 구현이 불가능한 함수들이 표준에 포함 되었기 때문입니다.

예를들어 std::is_integral<T> 는 해당 T type 이 정수형인가를 판정하는 함수인데, 이는 아주 단순하게 존재하는 모든 기본type 에 대해 해당 template 을 특수화 함으로서 해결하였습니다. 그 일부를 보면

 

01.png

 

대략 뭐 이런식이죠.

 

하지만 std::is_enum<T>, std::has_virtual_destructor<T> 등은 분명 라이브러리 형태로 제공 되어야 하나, 어떤 방법으로도 해당 정보를 프로그래머가 얻어낼 수 없습니다. 그렇다고 해당기능을 연산자로 넣기에는 너무 많은 연산자가 추가되어야 하고, 연산자 주제에 상당히 긴 이름을 가질 수 밖에 없는 문제가 있습니다. 물론 reinterpret_cast 같이 기존에도 이름이 긴 연산자가 있었으나, 이는 의도적으로 길게 만들어진 작명으로서 가능하면 쓰지 말라는 의미와 함께 만약 사용하였을 경우 눈에 잘 띄도록 하는 의미도 있습니다.

 

결국 언어에 문법을 추가되지 않았으나, 제공해야 하는 기능은 생겨 났고, 그 결과는 별 수 없이 컴파일러에 의해 코드가 자동 생성되도록 하는 대량의 컴파일러 확장키워드의 추가로 나타났습니다. 예를들어 VC++2015는 아래와 같은 매크로를 제공하는데, __(언더바 2개) 로 시작하는 함수는 전부 실제 존재하는것이 아닌 컴파일러가 컴파일 시점에 알아서 채워 주는 값들입니다.

 

// COMPILER SUPPORT MACROS

// VC++ V14 SUPPORT
  #define _IS_BASE_OF(_Base, _Der) \
: _Cat_base<__is_base_of(_Base, _Der)>
  #define _IS_CONVERTIBLE(_From, _To) \
: _Cat_base<__is_convertible_to(_From, _To)>
  #define _IS_UNION(_Ty) \
: _Cat_base<__is_union(_Ty)>
  #define _IS_CLASS(_Ty) \
: _Cat_base<__is_class(_Ty)>
  #define _IS_POD(_Ty) \
: _Cat_base<__is_pod(_Ty)>
  #define _IS_EMPTY(_Ty) \
: _Cat_base<__is_empty(_Ty)>
  #define _IS_POLYMORPHIC(_Ty) \
: _Cat_base<__is_polymorphic(_Ty)>
  #define _IS_ABSTRACT(_Ty) \
: _Cat_base<__is_abstract(_Ty)>
  #define _IS_FINAL(_Ty) \
: _Cat_base<__is_final(_Ty)>
  #define _IS_STANDARD_LAYOUT(_Ty) \
: _Cat_base<__is_standard_layout(_Ty)>
  #define _IS_TRIVIAL(_Ty) \
: _Cat_base<__is_trivial(_Ty)>
  #define _IS_TRIVIALLY_COPYABLE(_Ty) \
: _Cat_base<__is_trivially_copyable(_Ty)>
  #define _HAS_TRIVIAL_DESTRUCTOR(_Ty) \
: _Cat_base<__has_trivial_destructor(_Ty)>
  #define _HAS_VIRTUAL_DESTRUCTOR(_Ty) \
: _Cat_base<__has_virtual_destructor(_Ty)>
  #define _UNDERLYING_TYPE(_Ty) \
__underlying_type(_Ty)
  #define _IS_LITERAL_TYPE(_Ty) \
: _Cat_base<__is_literal_type(_Ty)>
  #define _IS_ENUM(_Ty) \
: _Cat_base<__is_enum(_Ty)>
  #define _IS_DESTRUCTIBLE(_Ty) \
: _Cat_base<__is_destructible(_Ty)>
  #define _IS_NOTHROW_ASSIGNABLE(_To, _From) \
: _Cat_base<__is_nothrow_assignable(_To, _From)>
  #define _IS_NOTHROW_DESTRUCTIBLE(_Ty) \
: _Cat_base<__is_nothrow_destructible(_Ty)>
  #define _IS_TRIVIALLY_ASSIGNABLE(_To, _From) \
: _Cat_base<__is_trivially_assignable(_To, _From)>
  #define _IS_CONSTRUCTIBLE \
__is_constructible
  #define _IS_NOTHROW_CONSTRUCTIBLE \
__is_nothrow_constructible
  #define _IS_TRIVIALLY_CONSTRUCTIBLE \
__is_trivially_constructible

 

 

전 이런 결과가 된 것이 언어가 제 컨트롤을 벗어난 것 같아 좀 아쉽기도 하고 한편으로는 라이브러리의 형태로 제공되느라 지저분해진 것들이 많은데(예를들면 std::map 이라거나 ... 요즘은 많은 언어들이 map 정도는 라이브러리가 아니라 문법차원에서 지원 하죠) 언어를 깔끔하게 만들기 위해선 좋다고 생각합니다. 

TAG •