cevin의 프로그래밍 블로그

이펙티브 C++씨를 보면 이러한 내용이 나옵니다.
1. C++에 왔으면 C++의 법을 따릅시다. 라는 장에서 C++의 하위언어에 대한 설명이 나오네요.
C, 객체지향개념의 C++, 템플릿 C++, STL입니다.
여기서 주목해야 하는 부분이 C를 제외한 객체지향C++, 템플릿C++, STL이 삼총사 군입니다.
제가 처음에 C++책을 샀을때는 C스타일의 코드와 C++이 합쳐진 듯한 스타일의 C++책이 전부였던걸로 기억합니다.
그때는 번역서를 안보고 쉽게 설명되있고 한글도 딱딱한 번역서가 아닌 한글책을 보다보니 그런부분이 좀더 있었죠.
근데 재밌는데 비슷한시기에 나온 외국 번역서는 이미 템플릿과 STL이 들어가 있다는 점입니다.

뭐 이건 시간되면 따로 쓰고싶은 주제이긴 합니다만 참 재밌는게 우리나라는 필요한 기술에 도입은 빠른데 그 이후에 좀더 잘 만들기 위한 기술에 도입은 생각이상으로 느리다는 점입니다.
간단한 예를 몇개 들어보자면 미국번역서의 C++책은 아무렇지 않게 템플릿 코드가 나오는부분입니다.
그것도 1990년대 후반책에서요....
또한 JAVA 3D책을 발견하고 뒤적거리던중 미국 아마존에서는 이미 1~5위를 Java 3D군이 휩쓸고 있더군요. 그때 우리나라에 딱 한권이 있었고..음..지금은 2~3권쯤 되던것 같습니다만..오프라인에서는 제가 봤었던 한권 외에는 본적이 없습니다.
하여튼..이런식으로 추가적인 신기술에서는 조금 굼뜬것 같은 느낌이 듭니다.
잘난체를 할려는건 아니고..그냥 근무환경등의 복합적인 문제로 생각해 주시면 감사하겠습니다.

하여튼 외국사람들이 그렇게 템플릿C++과 STL을 고집하는걸 보면 아마도 템플릿의 좀 난애한 가독성과 이해하기 위한 머릿속의 스택들을 뛰어넘은 장점이 있는것이라 생각을 하고 있습니다.

조금 이야기가 벗어났네요. 결론적으로 말씀드리고 싶은건 Ansi C++이 나온이상 최대한 표준스럽게 사용하는게 좋겠다는 뜻입니다. 물론 자기 마음대로 쓸수 있다는게 C++의 가장큰 장점이라고 할 수 있긴 하지만 적어도 그러한건 표준내에서 이루어짐이 맞지 않을까 하는 생각이 들어서 조금 건방져 보이게 글을 쓰게 됬습니다.

C++을 C++스럽게 쓰는건 이펙티브 씨리즈에서 가슴에 와닫도록 잘 설명하고 있으니 스윽 읽으시면 제가 제대로 표현못한 부분을 이해하시게 되지 않을까 싶습니다.

1. 기존 함수기반프로그래밍이었던 C에서는 입력과 출력에 대한 구조가 간결하였으나 (파라메터와 리턴값) 추가적으로 포인터를 이용한 레퍼런스를 따라하기 시작하였습니다. 그러한식으로 객제지향도 발달하고 그로 인해서 블랙박스식의 이용이라 할지언정 서로 알고 있어야 하는 규약들이 늘어났죠. (이건 저번에 템플릿을 좋아하는 이유의 글에서도 잠깐 적었던 적이 있습니다.)
그렇기 때문에 서로 알고 있는 부분이 많은것일수록 빨리 그리고 쉽게 개발을 할수 있겠다는 뜻입니다. 즉 서로가 가장 잘 알고 있는 공통분보로 개발을 하는것이 좋기 때문에 STL을 쓰면 좋다고 저는 생각합니다.

2. STL에서 만들어주는 각종 라이브러리를 사용할수 있으며, 우리가 손대지 않아도 계속 버전업 되고 가장 재밌는건 컴파일러 최적화에 가장 부합될수 있도록 각종 컴파일러들 및 STL구현자들이 노력하고 있다는 부분입니다.
특히 각종 만들어진 알고리즘들과 가장 궁합이 잘맞는(속도 및 안정성)것은 STL이라고 할수 있습니다.
마지막으로, 컴파일러 옵션과 머신에 따라서 프로그램 속도의 차이가 변하는 마당인데 오히려 한곳에서 만든 코드는 컴파일러가 바뀔때마다 틀려질수 있다고 생각합니다.

3. 엄청나게 많은 개발자들이 친절하게 QA를 열심히 해주고 있습니다. 덕분에 어지간한 환경 어지간한 문제는 거의 테스트 되고 있고 만일 되지 않더라도 곧 해결이 가능하다는 점이 있겠습니다.

4. 어떠한 라이브러리보다 일반적인 성능을 기대할 수 있습니다. 위에 컴파일 최적화나 머신에 따른 최적화랑 상당히 겹치는게 아닐까도 싶습니다만 STL만큼 생각보다 각종 변수가 많은 개발환경에서 일정한 성능을 기대할수 있는 라이브러리는 STL이라고 생각하구요, 혹시나 STL구현자가 다르더라도 우리가 숙지하고 있는 명세에 맞춰서 프로그래밍만 하면 STL은 반드시 그 부분을 만족시켜 줄꺼라 생각합니다.

그 외에도 이것저것 많을텐데....제가 생각하는 강력한 장점은 이정도인것 같습니다.

전 개인적으로 템플릿을 좋아합니다.
템플릿과 비템플릿 기법을 두고 했을때는 왠만하면 템플릿을
사용하는걸 추구하는 편입니다.

그러다 보니 자주 듣는말이 "그 보기 힘든걸 왜 좋아하냐?",
"템플릿은 남발하면 안된다." 라는 말이 대부분이더군요.

우선 간단한 이유인 "템플릿은 남발하면 안된다"라는 거에 대한 대답은
남발해야지 많은곳에 해볼수 있기 때문입니다.
그냥 새로운걸 해보자는 시도지요. 그리고 개인적으로 공부하다보니
남에 눈치를 안봐도 되는 경향도 있지요.
그리고 가장 중요한 이유는 아래 좋아하는 이유에 대한 설명을 보시면
이해가 되실것으로 예상됩니다.

그럼 다음 질문인 "그 보기 힘든걸 왜 좋아하냐?"라는 질문입니다.
저도 템플릿은 처음 본건 AI Programming Wisdom 이라는 책이었는데
처음 본순간 외계프로그래밍언어가 아닐까 생각이 들었었습니다.
그러던중에 Accelerated C++을 보고 STL에 대한 설명과 템플릿에 대한 기본적인
개념을 이해 할수 있게 되었고, 그 다음으로 읽었던 Modern C++ Design을 보고
템플릿이라는 문법에 대해 새로운 시각을 갖게 되었습니다.

그 이유인즉 "이걸 이용해서 이렇게 신기하고 범용적인 코드를 구현해 낼수 있구나."
라는 부분 이었습니다.

그렇다면 제가 느낀 부분을 설명드리겠습니다.

첫번째로 범용적, 일반적이라는 부분에 대해서 제가 생각하는 부분을 말해야 겠네요.
STL이 일반화라는 특징을 가진이유가 템플릿 인자를 매개로 받아 반복자, 컨테이너, 알고리즘
삼총사가 분리되어 있다는 점이라고 말하고 있습니다.
하지만 정말로 그러한 부분이 일반적이고 범용적인 이유일까요?
Effective C++(More포함)을 읽어보신 분들은 정확히 컨테이너에 따라 사용방법이 틀려야
한다는것을 알고 계실꺼라 생각합니다.
(물론 대체적으로 공통적인 동작방식으로 이루어져 있습니다.^^;)

하지만 저는 그 부분보다는 어떠한 자료구조도 인식할수 있다는 점, 즉 특정자료구조나 특정
설계구조에서만 돌아갈 필요가 없다는 부분이 참 마음에 들었습니다.
사실 STL보다 템플릿을 더 미리 알고 STL을 보게 되서인지 그런부분이 더 눈에 들어왔었던것도 있었네요.

두번째로 제가 템플릿은 좋아하는 이유는 Modern Design C++ 1장에서 나오는 바로
"특히 디자인의 제한조건을 사용자에게 넘기는 "스스로의 제한조건"으로 넘기는
것은 템플릿 문법의 큰 장점입니다." 이 내용때문입니다.

혹시 SDK의 변경때문에 라이브러리를 전면적으로 개조해 보신적이 있으신가요?
혹시 남이 만들어 놓은 구조가 마음에 안들거나 현재 프로젝트에 적용할수 없다고 느끼신적은 없으신가요?
혹시 다양한 출력과 다양한 객체들을 서로 연결시켜야 해서 클래스를 여러개 만들어 보신적이 있으신가요?
템플릿은 이러한 모든것을 뛰어넘을수 있는 구조를 지원해 준다고 생각합니다.

SDK변경부분은 SDK에 종속적인 부분을 따로 띄어놓은 상태에서 언제든지 템플릿으로 변경 가능하도록 설계시
SDK버전뿐 아니라 SDK가 바뀌는 경우에도 그것을 이겨낼수 있습니다.
물론 크로스컴파일이나 #ifdef등으로 넣는 방법이 있긴 하지만 크로스 컴파일에서 낭비되는 속도와
#ifdef로 인해 코드가 복잡하다고 느껴보신적은 없으신가요?

남이 만든 코드를 접목시키려 할때 구조를 바로 사용할수 없어서 고쳐사용하는 경우가 있는데
근본적인 부분과 연결되어 있을시에는 곤란하지시 않으셨었나요?

이렇게 변경될수 있는 부분에 틈을 벌려놓을수 있다는 점이 템플릿 문법의 강점이라고 생각합니다.

또한 템플릿을 이용한 상속, 포함관계시 언제든 교체가능한 구조로 만들게 될시 그 단위단위의 템플릿은
어떠한 곳에서도 사용가능한 단위클래스가 됩니다. 항상 소프트웨어의 공학에서 강조하고 있는
코드의 재사용성을 정확히 부합시키는 코드를 많이 만들수 있게 된다는 것이지요.

제가 템플릿을 좋아하는건 위에 적어놓은 저부분이 전부입니다.
제가 적어놓은 부분이 정말로 강점으로 보이실지 아니면 단순한 말장난이나
쓸모없는 곳에 열올리는 이상한 사람으로 보일지 모르겠지만 강점으로 볼수 있도록
잘 설명이 되었기를 바랍니다.

(이번에 Modern C++ Design을 공부할일이 있어서 이곳에 같은 내용을 적게 됬습니다.
틀린내용이 있을수 있으니 가려서 보시기 바랍니다.)

소프트웨어 디자인을 제작중에 다양한 기능의 클래스를 제작할때 복잡해지는 문제와
코드의 재사용을 위해서는 단위전략 기반의 클래스 디자인이 좋고,
이러한 디자인은 템플릿 문법과 다중상속을 이용하면 서로의 단점을
보강하여 훌륭한 해결법이 될수 있습니다.
특히 디자인의 제한조건을 사용자에게 넘기는 "스스로의 제한조건"으로 넘기는
것은 템플릿 문법의 큰 장점입니다.

단위전략은 특정단위에 대한 작업을 특정클래스에 위임하는것인데 이러한
클래스를 단위전략 클래스라하며, 아마도 stl::map에서 마지막 템플릿 인자인
정렬용 함수객체가 이러한 단위전략클래스의 한 부류라 생각됩니다.

템플릿 인자로 단위전략을 할시에는 좋은점으로서는
1. 사용자가 원하는 모습으로 특정기능을 만들어 낼수 있다.
2. 템플릿 인자를 받아들이는 클래스는 하나의 틀로서 사용될수 있다.
3. 단위전략 클래스는 다른곳에서도 사용가능하다.
4. 사용자가 단위전략을 바꾸었을시 컴파일상에서 에러를 넘겨주므로 사용방법이
틀리더라도 어디에서 사용되고 있는지 알아내기 쉽다.
라는 장점을 가질수 있고
기존에 잘 만들어진 부분에는 특화템플릿 문법으로 처리하여 피해갈수 있습니다.

책에서 소개하는 단위전략클래스는 상속과 함깨 사용되는 부분에 대한 설명이라서
소멸자에 대한 문제가 나오는데 protected로 처리하여 외부에서 해제할수 없도록
막고 있으며, 단위전략 클래스를 받는 클래스에서 처리하도록 하고 있습니다.

단위전략 클래스를 조합하는 템플릿 클래스를 만들시 기존에 일일히 손으로
상속시켜 만든것을 컴파일러를 이용하여 코드생성을 할수 있는데, 이러한
부분을 단위전략 기반의 클래스 디자인의 또하나의 큰 장점으로 꼽고 있습니다.

단위전략 템플릿 클래스는 컴파일러 입장에서는 전혀 다른 클래스이므로
변환연산자를 지정하지 않는 이상 되지 않는다는 점을 상기시키고 있습니다.

마지막으로 클래스를 단위전략 클래스로 분류할때는 단위전략 클래스끼리
공통되는 부분이 없이 독립적인 단위전략 클래스를 구성할 것을 권고 하고 있습니다.

결론적으로 템플릿을 이용한 단위전략 클래스는 단위전략 컴포넌트의 조합으로
원하는 클래스를 생성해 낼수 있고 이러한 부분은 차후 재사용성등에도
사용가능하며, 확장성에도 좋으며, 기존에 가상클래스를 기반으로
설계한 구성보다 단위전략이 바뀌었을때 컴파일 에러를 통하여
알수 있으므로 좋으며, 마지막으로 디자인의 제한조건을 사용자에게 넘길수 있으므로
사용자가 사용하기에 편하다는 장점이 있습니다.