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

2. 시작하기 전에 결론은
예외기능을 지원하지 않도록 컴파일 하라

3. 리소스 누수방지는 소멸자로
• 지역리소스(스택 할당)를 물고 있는 포인터와 이별하자
• 매번 예외에 delete를 통해 처리해줘야 한다.
• Try-catch문은 코드가 복잡해질 뿐만 아니라 여러 문제를 안고 있
다.
• 소멸자에 delete를 물고 있는 객체인 스마트 포인터를 사용하자
• 윈도우 시스템 API들은 c스타일의 인터페이스를 가지고 있다.

4. 윈도우 시스템 API들의 관리법
• 리소스를 얻어내는 생성자와 해제하는 소멸자를 가진 객체를 이
용하여 c스타일 API들을 관리하자

5. 생성자에서는 누수가 일어나지 않도록
• Operator new는 예외를 발생시킬 위험이 있다.
• C++에서는 생성이 안전하게 완료된 객체에 관해서만 소멸자를
호출한다.
• 이런 점을 염두하고 생성자를 설계해야 한다.
• 스마트 포인터를 사용하면 까다로운 설계문제들을 쉽게 해결할
수 있다.

6. 소멸자에서는 예외가 탈출할 수 없도록
• 소멸자가 호출되는 경우는 두 가지이다.
• 첫째는 통상적인 소멸이다. 즉 지역변수로 생성된 객체가 유효범
위에서 벗어나 소멸되는 경우이다.
• 둘째의 경우는 예외처리 메커니즘에 의해 객체가 소멸될 경우이
다.
• 하지만 소멸자 안에서는 어느 경우에 호출되었는지 알 수 있는
방법이 없다.

7. 소멸자 작성시 예외가 발생한 상태로 가정하자
• 소멸자를 작성할 때 방어적으로 작성해야 한다.
• 예외처리가 진행되고 있는 도중 또 다른 예외 때문에 흐름이 소
멸자 함수를 떠나면 C++에서는 terminate함수를 호출한다.
• Terminate함수 호출 시 칼같이 종료시켜버리기 때문에 지역객체
조차도 소멸되지 않는다.
• 따라서 소멸자 안에서 예외가 발생할 경우 소멸자를 탈출하게 되
는 경우를 만들지 말아야 한다.

8. 예외 발생은 매개변수전달, 가상함수 호출과 다르다.
• 함수의 매개변수 선언과 catch문은 생긴 것도 역할도 비슷하다.
• 함수의 호출은 함수 종료시 흐름이 호출한 부분으로 다시 돌아오
지만 catch문은 throw를 호출한 부분으로 다시 돌아오지 않는
다.(goto문과 비슷하다. 흐림을 깨버린다.)
• 예외를 처리할 때 인자가 Catch by value가 되든 Catch by
reference가 되든 사본생성이 이루어진다. 다만 사본 생성 횟수
가 다르다. Value는 2번 Reference는 1번 생성된다.
• 포인터에 의한 전달은 함수랑 같다.
• 지역객체에 대한 포인터는 넘겨봐야 소용없다. 결국은 유효범위
를 넘어서면 소멸되기 때문이다.

9. 동적 타입과 정적 타입 복사
• 예외를 던질 때는 상수 참조자를 사용할 필요는 없다. 그냥 참조
자를 사용할 수 있다.
• 예외를 전파하는 경우 rethrow를 이용하자. Rethrow는 객체의 복
사가 일어나지 않는다.
• Rethorw란 catch문안에서 throw;를 했을 때를 뜻한다.

10. 예외와 타입변환
• 기본적으로 예외는 암시적인 타입변환이 일어나지 않는다.
• 다만 상속관계의 타입과 포인터로부터 void*로의 타입변환은 허
용된다.
• 예외처리 메커니즘은 „가장 첫째의 것을 선택하는‟ 메커니즘을 따
릅니다.
Try catch문 자동완성을 vs에서 사용하면 이
렇게 기본적으로 3개의 catch문이 생성된다.
아래로 갈수록 부모이다.

11. 발생한 예외는 참조자로
• C++에서 제공하는 표준예외는 전부 포인터가 아니다.
• Catch by pointer는 좋은 방법이 아니다.
• 전역변수나 힙에 할당된 경우에만 유용할 뿐더러 관리도 힘들고
delete여부도 알기 힘들다.
• Catch by value는 2번 사본이 생성될 뿐만 아니라 slicing
problem을 가지고 있다.
• Slicing problem은 부모의 객체영역만 복사되어 자식의 영역이
잘려나가는 현상이다.

12. 예외지정기능은 냉철하게
• 함수가 발생시킬 예외를 미리 생성할 때 지정하는 것을 예외지정
이라고 한다.
• 예외지정에 일관성이 없을 경우 컴파일 도중 발견해주고 함수가
예외지정 리스트에 없는 예외를 발생시킬 경우 런타임 에러와 함
께 unexpected라는 특수 함수가 자동으로 호출된다.
• 문제는 unexpected함수가 terminate를 호출하는데 이에 대해서
는 알고 있듯 그냥 프로그램이 멈추어 버린다.
• Unexpected함수는 매우 쉽게 호출될 수 있는 함수이기 때문에
예외지정은 신중하게 사용해야 한다.

13. Unexpected함수의 나락을 막는 법
• 예외 지정된 새로운 코드와 예외지정이 안된 옛날 코드가 섞일
수 있기 때문에 조심하자
• 예외지정이 안 된 함수를 호출할 가능성을 가진 함수에는 예외
지정을 두지 않는다.
• 템플릿과 예외지정은 어울리지 않는다 사용하지 말자
• “시스템”이 일으킬 가능성이 있는 예외(C++표준 예외)를 처리하
자
• 아래와 같은 명령을 통해 unexpected함수를 대체할 사용자의 함
수를 만든다.

14. 예외처리에 드는 비용
• 예외처리를 검사하기 위해서 들어가는 내부적인 비용은 존재한
다.
• 예외기능이 들어가지 않는 라이브러리를 제작하기로 결정했다면
예외기능 없이 컴파일 하는 것이 코드 최적화에 상당한 기능을
준다.
• Try블록으로 인해 생기는 비용이 있다. 쓸데없이 try블록을 남발
해서는 안 된다.
• 우선 가능하다면 예외기능을 지원하지 않도록 컴파일 하라.

15. 80 - 20
• 프로그램 리소스의 80%는 전체 실행 코드의 20%만이 사용한다.
• 실행의 핵심을 담당하는 코드 20%를 이해하고 이 부분을 효율적
으로 만들어야 한다.
• 대부분의 프로그래머들은 자신이 짠 코드가 어느 정도의 수행 성
능을 가지고 있는지 파악하지 못하고 있다.
• 프로파일러를 사용하여 20%부분을 찾아내자
• 20%를 뚫어보는 능력이 필요하다.

16. 지연평가는 충분히 고려할 만하다
• 작업 결과가 진짜로 필요해질 때까지 그 처리를 미룬다. 예를 들
어 게임 프레임 60이하로 떨어지기 전까지는 고려하지 않아도 된
다.
• 진짜 필요해지기 전까지는 자기만의 데이터 사본을 만들지 않고
남의 것을 끌어다 사용한다
• „지연된 데이터 가져오기‟ 해당하는 데이터가 진짜로 필요할 경우
에만 가져오는 기법이다. 그 전까지는 메모리에는 객체의 껍데기
만 있다.
• 결과가 같은 동작을 여러 번 해야 할 경우 미리 그 결과를 저장해
놓고 사용한다.

17. 예상되는 결과를 미리 준비하자
• 미리 준비하면 처리 비용을 절약할 수 있다.
• 상당히 자주 요구될 것 같은 계산이 있다면, 그 요구를 효율적으
로 처리할 수 있는 자료구조를 설계하여 비용을 낮추자.
• STL사용시 iter->second가 아닌 *(iter).second 이런 형태로
iterator를 사용하자
• CPU의 연산을 메모리로 돌릴 수 있다. 즉 메모리를 쓸 수록 속도
가 빨라진다.

18. 임시 객체의 근원을 정확히 이해하자
• 임시 객체란 우리코드에 보이지 않는 임시로 만들어진 „이름 없
는‟ 객체이다.
• 함수호출을 성사시키기 위한 암시적 타입변환이 적용 될 때 생성
된다.
• Return by value를 할 때 생성된다.
• 암시적 타입 변환이 일어나는 경우는 오직 객체가 값으로 전달
될 경우와 reference to const(상수 참조자)가 전달될 경우이다.
• 객체를 value로 반환하는 대부분의 함수는 반환 시 임시객체를
피할 수 없다. 컴파일러의 최적화만 믿을 뿐이다.

19. 반환 값 최적화가 가능하도록 하자
• 지역 변수의 값을 참조자로 반환하거나 포인터로 반환하는 일은
하지 말자.
• 컴파일러가 최적화 가능한 형태로 코드를 작성하자.

20. 오버로딩은 불필요한 암시적 타입변환을 막는다.
• 암시적 타입변환은 정말 편리하지만 임시객체의 생성은 우리가
원하지 않는다.
• 함수의 오버로딩을 통해 다양한 경우에 대해 준비함으로써 암시
적 타입변환을 막을 수 있다.
• 오버로딩 되는 연산자 함수는 반드시 최소한 한 개 이상의 사용
자타입이 인자로 들어가야 한다.
• 물론 프로그램의 효율은 고려하자 사용하지도 않는 함수를 쌓아
놓지 말자.

21. +보다 +=을 사용할 수 있으면 하자
• 연산자를 만들어서 사용할 때 대입 연산자를 통해 단독 연산자를
작성하면 자연스럽게 두 연산자를 관계 지어 둘 수 있다.
• 대입 연산자는 임시객체를 만들지 않기 때문에 효율적이다.
• 대입 연산자는 매우 편리하다.
• 대입 연산자를 통해 단독 연산자를 작성할 때 이름없는 형태의
임시객체를 만들어 반환 할 수 있기 때문에 임시객체 최적화를
컴파일러에게 부탁할 수 있다.(슬라이드 19장 참고)

22. 정 안 되면 다른 라이브러리 쓰자
• 사용하는 라이브러리에서 병목현상이 발견된다면 그냥 라이브러
리를 바꿔라. 비슷한 걸로.
• 라이브러리만 바꿔도 눈에 띄게 수행성능이 달라질 수 있다.
• Stdio가 iostream보다 지금은 빠르지만 iostream이 stdio보다 빨
라질 수 있는 날이 올 수도 있다.
• 아마 그땐 내가 은퇴했을지도(….)

23. 가상함수, 다중상속, 가상 기본 클래스, RTTI 의 비용
• 가상함수가 생성될 때 가상 테이블(vtbl)과 가상 테이블 포인터
(vptr)가 함께 생성된다.
• Vtbl은 함수포인터의 배열이며 가상함수의 선언 뿐만 아니라 상
속받은 클래스에도 생성된다. 그리고 가상함수의 시작주소(함수
포인터)를 물고있다.
• 컴파일러가 필요한 목적파일마다 vtbl을 생성하고 링커가 중복을
제거해주거나 heuristic이라는 규칙을 사용해서 vtbl을 가질 목적
파일을 결정해준다.
• Inline도 아니고 순수가상 함수도 아닌 함수 중 첫 번째 정의부분
에 vtbl을 넣기로 하는 규칙이다.
• Heuristic규칙은 가상함수를 inline으로 너무 많이 선언할 때 적용
할 수 없게 된다.

24. 가상 함수
• Virtual의 의미는 “호출 할 함수를 런타임까지 기다려서 결정한다.”
이다.
• Vptr은 „어떤 객체에 대해 어떤 vtbl을 사용할 것인가‟를 결정한다.
• 해당하는 클래스의 숨겨진 데이터 멤버 변수형태로 선언된다.
• 가상함수만 놓고 수행성능의 발목을 잡는다고 보기는 힘들다. 고
작 명령어 몇 개가 더 실행되는 수준이다.
• 가상함수는 inline을 포기해야 한다. (참조자나 포인터를 사용할
경우에만 해당되지만 일반적으로 참조자나 포인터만 사용한다.)

25. 가상 기본 클래스
• 이것이 없으면 하나의 파생클래스에서 기본클래스까지의 길이
두 가지일 때 기본클래스가 중복되는 현상이 발생하기 때문에 필
요하다.
• 잘 생각하고 사용해야 한다. 각각에 대해서 vptr과 vtbl이 생성되
기 때문이다.

26. RTTI 런타임 타입 식별
• RTTI는 실행 중에 객체와 클래스의 정보를 알아낼 수 있지만 이
정보를 저장할 메모리가 당연히 필요하다.
• 이 정보는 type_info라는 객체에 저장되며, typeid연산자를 사용
해서 액세스할 수 있다.
• RTTL은 vtbl을 통해서만 구현될 수 있도록 설계되었기 때문에 해
당 클래스에 가상함수가 하나는 꼭 들어있어야 한다.