1. Effective C++_4
131043 양현찬
NHN NEXT

2. 템플릿
•튜링 완전성
•템플릿 메타프로그래밍
완벽에 가까운 언어 C++

3. 암시적 인터페이스와 컴파일 타임 다형성

4. 우리는 SkinnedMesh의 구조를 코드를 통해 바로 알 수 있고 이 구조를 따라야만 한다.
이러한 형태를 명시적 인터페이스라고 한다.
가상 함수가 존재한다. 이 가상함수에 대한 호출은 런타임 다형성에 의해 이루어 진다.

5. 반대로
아래의 템플릿이 제대로 컴파일 되기 위해서는 Type T는 SetHP(), State() 등이 지원되어야 하는데
obj가 수반되는(operator==등등) 함수가 호출 될 때는 컴파일 도중 템플릿의 인스턴스화가 일어난다.
obj에 어떤 매개변수가 들어가느냐에 따라 호출되는 함수가 달라질 수 있다.
이러한 성질을 컴파일 타임 다형성이라 한다.
이들을 T가 지원해야 하는 암시적 인터페이스라 한다.

6. 말이 어렵다 하지만 풀어보면 별거 없다
• 우리가 클래스 인스턴스 만들어 사용하듯 템플릿도 매개변수에
맞는 인스턴스를 만들어야 한다. 이를 템플릿의 인스턴스화라 한
다.
• 이 과정은 매개변수마다 다르니 컴파일 과정에서 확인된다. 따라
서 컴파일 타임 다형성이라 부른다.
• 암시적 인터페이스를 표현식이라 한다.

7. Typename의 두 얼굴

9. 마치 C++에서 struct와 class 차이 같다.
왜 나눠났을까?
Struct/Class말고
Class/Typename

10. 두 가지 이름
iter는 C의 타입에 따라 달라진다. 이를 의존이름이라 한다.
Value는 C의 타입과는 전혀 상관없다. 이를 비의존 이름이라 한다.
위 코드는 문제가 많다.
우연히 T::const_iterator가 같은 이름을 가진 정적 변수라면?
모든 경우의 수에 대해 안전해야 한다.
T::const_iterator는 중첩가능성이 있다. 이를 중첩의존이름이라 한다.

11. 타입이라고 명시하자
T::const_iterator가 변수이름 따위가 아니라 타입임을 명시하고 있다.

12. 잘 사용하자
뭐… 통일성 없는 점이 언어의 특징이다…

13. 하나만 더
만약 iterator를 매개변수로 하는 함수를 만들고 싶을 경우
너무 길어서 못마땅하다면 typedef 씁시다.

14. 템플릿으로 만들어진 기본 클래스 안의 이름에 접근

15. 클라이언트 사이의 메시지 통신을 위해 만든 객체들

16. 로그는 습관이니 로그를 남기도록 합시다.
MsgSender<client>를 상속받았음에도 불구하고 sendClear를 컴파일러는 알지 못한다.
컴파일러는 client가 정확하게 무엇인지 모르는 상황에서 어디서 파생된 것인지 알지를 못한다!

17. 더 파고들면
만약 서버가 메시지를 전송할 때는 꼭 암호화해서 보낸다고 하자
ServerA에만 필요한 특수한 형태의 MsgSender가 필요하다.
완전 템플릿 특수화
오로지 ServerA타입에 대해서 특수한 형태로 사용하도록 하고 있다.
만약 템플릿LogMsgSender에 ServerA가 들어가게 된다면 MsgSender는 SendClear가 없는 상황이다!

18. 방법은 많습니다.
sendClear가 상속될 때 만을 가정한다.
만약 ServerA같은 타입이 client에 들어갈 경우 컴파일 에러가 난다.
This를 사용
Using을 사용
상속받음을 명시

19. 매개변수에 독립적이면 템플릿에서 분리시키자

20. inline과 마찬가지로
• Template도 막 쓰면 오히려 코드비대화 현상이 일어난다.
• 공통성 및 가변성 분석을 하자.
• 뭐.. 이름만 어렵지 우리가 늘 해오던 짓이다.
• 다만… 템플릿은 암시적이다.
• 일반적으로 함수로 묶은 코드중복 방지는 명시적이지만
• 템플릿은 코드중복을 어떻게 해소하는지 암시적이다

21. 암시적?
각각의 invert의 사본이 인스턴스화 된다.
둘이 같은
가?아니
다!오히려 코드 비대화를 일으키고 있다.

22. 일단, 해결방안
상속받은 클래스의 invert가 가려지는 것을 막기 위해 using사용
오로지 사본을 피할 목적이기 때문에 protected를 사용하고 있다.
단순히 구현을 돕기 위한 용도이기 때문에 private을 이용
This는 이미 위에서 using이 사용되었으니 불필요하다
매개변수로 조건을 넣어준다
아직 멀었다! 계산을 위한 행렬 데이터가 SquareMatrix에 있을
경우 SquareMatrixBase의 invert 계산은 어떻게 하냐?

23. 전달할 구멍을 만들
자.생성자를 통해 전달하거나 SetDataPtr함수를 통해 전달할 수 있다.

24. “호환되는 모든 타입”은 멤버 함수 템플릿

25. 스마트포인터가 좋다고 배웠다
하지만 스마트포인터가 흉내내지 못하는 기능이 일반 포인터에게 있다.
바로 암시적 변환이다.

26. 이렇게 하고 싶은데..
하지만 컴파일러는 용서하지 않는다.
템플릿에 의해 만들어진 인스턴스 사이는 아무 관계가 없다.

27. 그러면 만들자
멤버 함수 템플릿
모든 T와 U타입에 대하여 SmartPtr<T>객체가 SmartPtr<U>로부터 생성될 수 있다.
일반 복사 생성자라고 한다.
하지만… 우리가 원하는 영역보다 더 많은 영역을 만들어낼 수 있다.
예를 들면 자식에서 부모, 자식에서 부모까지도 가능하도록 하고 있다.

28. 그냥은 안 된다
스마트포인터는 복사할 때 사본을 반환한다. 이점을 이용하여 여기서도 사본을 반환하고 있다.
결국 포인터의 암시적 변환을 이용하고 있다.

29. 멤버 함수 템플릿의 활용
같은 shared_ptr에서의 암시적 변환은 허용되지만 다른 타입으로 부터의 변환은 허용하지 않고 있다.
여기만 explicit이 없다
마지막으로, 일반화 복사 생성자는 컴파일러가 만드는 복사 생성자를 막는 요소가 아니다.

30. 타입변환이 바람직할 경우 비멤버 함수를 클래스 템플릿 안에 정의해 두자

31. 문제인식
템플릿으로 선언된 클래스가 있다.
해당하는 클래스를 연산해주는 operator*함수가 밖에 선언되어있다.

32. 문제가 없는 것 같지만 아래코드를 컴파일 하면 에러가 난다.
지금의 경우 operator*함수를 호출 할 때 어떤 함수를 호출하려는지 알 수 없다.
operator*의 템플릿 T가 무엇인지 모르기 때문이다.
oneHalf의 T가 int형임은 쉽게 알 수 있다. 하지만 2의 경우는 어떻게 처리할 것인가?
컴파일러는 템플릿 인자 추론과정에서 암시적 변환을 고려하지 않는다.
컴파일러는 템플릿 인자 추론을 통해 인자를 찾는다.

33. 인자추론의 수고를 덜자
템플릿 인자추론은 클래스 템플릿에서는 일어나지 않는다.
T의 정보는 해당 클래스가 인스턴스화 되는 순간 알 수 있다.
문제는 컴파일은 되는데 링크가 안 된다….
외부 함수인 operator*함수를 선언만 했지 정의가 안되어 있기 때문이다.
비멤버 함수를 선언하는 방법이 friend밖에 없다.

34. 최종코드
내부 구현을 추가하고 있다.

35. 타입에 대한 정보가 필요하다면 특성정보 클래스를 사용하자

36. STL구성
• 컨테이너
• 반복자
• 알고리즘
• 유틸리티

37. advance
반복자를 지정된 거리만큼 이동시키고 있다.
Iter += d같은 연산이 불가능하기 때문에 필요하다.
임의 접근 반복자만 위 같은 연산이 가능하다.

38. 반복자의 종류
• 입력 반복자(읽기 전용 파일포인터 연상, 한번만 읽을 수 있음)
• 출력 반복자(위에서 오로지 쓰기만 가능하도록 바뀜)
• 순방향 반복자(여러 번 읽고 쓰기 가능)
• 양방향 반복자(순방향에서 양방향만 추가)
• 임의 접근 반복자(반복자 산술연산 추가)

39. 태그 구조체
반복자들의 범주를 식별하는데 사용되는 구조체들

40. 돌아와서
Advance를 구현할 때 iter가 어느 종류의 반복자인지 확인할 필요가 있다.
여기서 특성정보를 사용한다.
특성정보란 컴파일 도중에 어떤 주어진 타입의 정보를 얻을 수 있게 하는 객체를 지칭한다.

41. 특성정보
• 문법구조도 아니며 키워드도 아니다.
• 그저 구현기법이며 관례이다.
• 특성정보는 기본제공 타입과 사용자 정의 타입에서 모두 돌아가
야 한다.
• 어떤 타입 안에서는 구현이 불가능하기 때문에 외부에서 특성정
보를 가지고 있는 무언가가 필요하다.

42. 반복자의 경우
반복자용 구성정보는 표준에 이미 구현되어있다.
Struct으로 구현하는 것이 관례다.
„특성정보 클래스‟라고 부른다.
뭐… 어차피.. 둘은 같으
니.

43. 내부구조
위처럼 _Iter타입의 내부 정보들을 typedef로 가지고 있다.
위 구조는 사용자 정의 타입에서는 잘 돌아가지만, 반복자가 포인터일 경우 전혀 동작하지 않는다.

44. 사용자 정의 타입일 경우
사용하고 있는 iterator의 태그 구조체를 iterator_category로 typedef한다.
태그 구조체는 iterator의 종류에 따라 다르다.

45. 포인터일 경우
포인터 버전을 따로 제공하고 있다.
직접 헤더파일에 들어가보면 경우의 수에 대해서 다른 버전을 지원하는 것을 볼 수 있다.
이러한 형태를 부분 템플릿 특수화라고 한다.

46. 다시 돌아가서
라고 하면 될 것 같지만... 문제가 많다.
Typeid는 간단하게 타입을 취하는 연산자다.
if문은 컴파일이 다되고 런타임 도중 평가되기 때문에 오히려 코드가 비대해진다.
또 컴파일도 에러가 난다. 그건 나중에 설명..

47. If문을 제거하자
오버로딩을 통해 비슷한 효과를 낼 수 있다.
오버로딩 버전이 여러 가지일 경우 컴파일러는 가장 상황에 잘 맞는 버전에 접근한다.
예외처리

48. 템플릿 메타프로그래밍, 하지 않겠는가?

49. 템플릿 메타프로그래밍
• 컴파일 도중에 실행되는 템플릿 기반의 프로그램 작성
• 즉 컴파일러가 실행시키는 프로그램….
• 실행이 완료된 산출물은 다시 C++코드로 들어가 컴파일 된다.
• 런타임 영역의 연산을 컴파일시간으로 합쳐버릴 수 있다.
• 까다롭거나 불가능한 일도 해낸다.

50. 또 다시 돌아가서
아까 문제가 되었던 advance 코드
컴파일을 해보면 에러가 난
다.바로 += 부분인데 이 부분은 if문에 의해 정해진 조건일 때만 실행될 것이다. 그런데 왜 나는 것일까?
If문은 런타임 도중에 실행된다. Template은 컴파일 도중 실행된다.
컴파일 도중에 iter를 체크하기 때문에 +=의 오류를 컴파일러는 잡을 수 밖에 없다.

51. Let‟s TMP
• 루프가 없다… 헐..
• 루프효과를 내기 위해서 재귀함수를 이용한다.
• 이 재귀함수조차도 우리가 아는 형태가 아니다.
• 재귀식 탬플릿 인스턴스화를 이용한다.
• 다행이 TMP용 라이브러리들도 꽤 있다.

52. 하지 않겠는가?
나열자 둔갑술을 이용해 value에 값을 넣고 있다.
탈출 조건을 정의하고 있다.
우왕ㅋ 굿ㅋ

53. 내 힘을 보여주지
• 치수단위의 정확성 확인
• 행렬 연산의 최적화
• 맞춤식 디자인 패턴 구현의 생성

54. new부터 알자

55. new의 뒷처리 담당
new처리자라고 하며 메모리할당 도중 문제발생시 우선적으로 호출하도록 하고 있다.
사용은 이렇게 한다.
위 코드를 실행시키니 아무 일도 안 일어난 점이 함정
new는 할당 받을 충분한 공간이 없으면 내부적
으로 순환하면서 계속 공간을 찾는다.
이때 처리자도 계속 반복 호출된다.

56. 처리자 함수의 형태
• 사용할 수 있는 메모리를 더 확보
• 다른 new 처리자를 설치
• new 처리자 설치를 제거(null을 집어넣는다.)
• 예외를 던짐
• 복귀하지 않음(꺼버림)

57. 이렇게 하고 싶다면
MainCharacter와 엑스트라는 비중이 다르기 때문에 서로 다른 에러처리를 하고 싶다면
따로 제공되는 방법은 없다. 그냥 직접 만들면 된다.

58. 이러한 방식의 에러처리 코드를 다른 클래스에서도 재사용 하고 싶다.
그럴 경우 믹스인 양식을 사용하자.
즉, 다른 파생 클래스들이 한 가지의 특정 기능만을 물려받아 갈 수 있도록 설계된 기본클래스를 만든다.

59. 이러한 방식으로 파생되는 자식을 인자로 받는 템플릿 클래스를
신기하게 반복되는 템플릿 패턴 이라고 불린다.

60. new 및 delete를 언제 바꿔야 할까

61. 왜 new연산자를 바꾸고 싶을까
• 잘못된 힙 사용을 탐지하기 위해
• 효율을 향상시키기 위해
• 동적 할당 메모리의 실제 사용에 관한 통계 정보를 수집하기 위해
• 할당 및 해제 속력을 높이기 위해
• 기본 메모리 관리자의 공간 오버헤드를 줄이기 위해
• 적당히 타협한 기본 할당자의 바이트 정렬 동작을 보장하기 위해
• 임의의 관계를 맺고 있는 객체들을 한군데로 나란히 모아놓기 위해
• 그때그때 원하는 동작을 수행하기 위해

62. new및 delete를 작성 할 때 따라야 할 기존의 관례를 잘 알아 두자

63. 0바이트를 요구하면 1바이트를 할당한다…
할당이 될 때까지 루프를 돈다.
돌때마다 bad_alloc()을 날려준다.

64. 0이 들어오면 그냥 끝내버린다.

65. 위치지정 new라면 위치지정 delete도 같이 준비하자

66. 우리는 짝을 맞춰야 함을 알고 있다.
operator new를 터치했으면 operator delete도 이에 맞게 만들어야 한다.
위 형태는 잘못되었다.

67. 추가 매개변수를 받는 new
new에 추가로 매개변수를 설정했으니
delete도 추가로 해주어야 합니다.
추가 매개변수를 개념적으로 위치지정 이라고 합니다.
짝이 없이 delete를 호출해도 어떤 delete도 호출되지 않습니다.

68. 표준형에서 확장하는 형태로 만들어 갑시다.

69. 마지막으로

70. 컴파일러의 경고를 지나치지 말자!
TR1을 포함한 표준과 친해지자!
부스트를 늘 가까이하자!
부스트는 심사를 거치는 오픈소스 라이브러리가 계발되는 모임이다.

71. 입사하고 안정되면 다시 이 책을 보고 요약합시다.