Effective C++-2-

채원

3. 자원관리

자원은 썼으면 반환하는 것이 원칙->C++ 의 생성자 , 소멸자 , 객체 복사 함수를 이용하면 편하다

항목 13: 자원관리에는 객체가 그만

auto_ptr[ 스마트 포인터 ] 는 가리키는 객체가 소멸할 때 자동으로 delete 를 불러준다 .-> 한 객체를 가리키는 auto_ptr 은 반드시 하나여야 한다 . 복사하면 이전의 것은 null 을 가리킨다 .

auto_ptr 을 사용할 수 없을 때는 RCSP[ 참조 카운팅 방식 스마트 포인터 ] 를 사용한다 .

항목 13: 자원관리에는 객체가 그만

RCSP 의 대표적인 예 : std::tr1::shared_ptr<>

특정한 자원을 참조하는 외부 객체의 수를 가지고 있다가 0이되면 해당 자원을 삭제한다

항목 13: 자원관리에는 객체가 그만

둘다 소멸자 내부에서 delete 를 작동시킨다 -> 동적 배열에 사용하면 난감 ! -> vector 나 string 으로 대체

정 쓰고싶으면 부스트를 쓰자 .

항목 14: 자원관리 클래스의 복사동작에 대해 진지하게 고찰하자

힙에 생기지 않는 자원 관리는 ? Bb

-> 자원 관리 클래스를 직접 만들어야 할 수도 있다 ex) mu-tex : 락을 걸면 반드시 풀어준다

-> RAII 방식을 따라 생성자에서 자원을 획득하고 , 소멸자에서 그 자원을 해제한다

항목 14: 자원관리 클래스의 복사동작에 대해 진지하게 고찰하자

RAII 객체를 복사할 때 어쩌지 ?

-> 복사를 금지한다-> 관리하고 있는 자원에 참조 카운팅을 한다 : shared_ptr 을 이용한다 . 대신 삭제자 [ 참조 카운트가 0 이 되었을 때 호출되는 ] 를 지정해줄 수 있다 . Tr1::shared_ptr 생성자의 두번째 매개변수로 넣어줄 수 있다 . 이제 그 클래스는 소멸자를 선언하지 않고 컴파일러가 자동으로 만들어주는 소멸자로 동작한다 .

항목 14: 자원관리 클래스의 복사동작에 대해 진지하게 고찰하자

RAII 객체를 복사할 때 어쩌지 ?

-> 관리하는 객체를 진짜로 복사한다 . 그 객체가 관리하는 자원까지 deep 하게 복사한다 새로운 힙 메모리를 갖게됨-> 관리하고 있는 자원의 소유권을 옮긴다 . Ex: auto_ptr

항목 15: 자원관리 클래스에서 관리되는 자원은 외부에서 접근할 수 있도록 하자

RAII 클래스의 객체를 그 객체가 감싸고 있는 실제 자원으로 변환할 방법이 필요

-> 명시적 변환 : get() :RAII 안의 자원의 포인터를 얻을 수 있다-> 암시적 변환 : -> 와 * 의 연산자 오버로딩 ! 암시적 변환 함수를 직접 제공하도록 만든다

항목 15: 자원관리 클래스에서 관리되는 자원은 외부에서 접근할 수 있도록 하자

원하지 않는 타입 변환이 일어나기 쉬우니 , get 과 같은 명시적 함수 변환을 제공하는 것이 낫다 .

캡슐화 : shared_ptr 은 참조 카운팅 메커니즘 관련은 꼼꼼히 캡슐화 하되 , 자신이 관리하는 포인터에 접근할 수 있도록 느긋한 캡슐화 !

항목 16:new 및 delete 를 사용할 때는 형태를 반드시 맞추자

new 에 [] 를 썼으면 delete 에도 [] 를 쓰고 , new 에 [] 를 안썼으면 delete 에도 [] 를 쓰지말자

항목 17: new 로 생성한 객체를 스마트 포인터에 저장하는 코드는 별도의 한 문장으로 만들자

컴파일러 순서는 보장되있지 않기 때문에 , 예외가 발생하면 디버깅하기 힘든 자원 누수가 발생한다 .

4. 설계 및 선언

좋은 인터페이스 설계를 위해서는 !

항목 18: 인터페이스 설계는 제대로 쓰기엔 쉽게 , 엉터리로 쓰기엔 어렵게 하자

제대로 쓰기 쉽게 , 엉터리로 쓰기 어렵도록 매개변수 타입을 만들어주면 좋다 .

인터페이스 사이의 일관성을 맞춰준다

기본 제공 타입과의 호환성을 유지한다 .

자원 관리는 기본적으로 지원한다 .

항목 19: 클래스 설계는 타입 설계와 똑같이 취급하자

항목 19: 클래스 설계는 타입 설계와 똑같이 취급하자

항목 19: 클래스 설계는 타입 설계와 똑같이 취급하자

항목 19: 클래스 설계는 타입 설계와 똑같이 취급하자

항목 19: 클래스 설계는 타입 설계와 똑같이 취급하자

항목 20:’ 값에 의한 전달’보다는 ‘상수객체 참조자에 의한 전달’ 방식을 택하는 편이 대개 낫다

말 그대로 값에 의한 전달은 별로다 .상수 객체 참조자에 의한 전달 방식을 택하자 .-> 대신 기본제공 타입 , STL 반복자 , 함수객체 타입에는 맞지 않다 .

항목 21: 함수에서 객체를 반환해야 할 경우에 참조자를 반환하려고 들지 말자

포인터나 참조자는 반환하는 물건이 아닙니다 .하지마세요 .

항목 22: 데이터 멤버가 선언될 곳은 private 영역임을 명심하자

데이터 멤버는 private 영역에 선언합니다 .protected 는 괜찮아 보이지만 결국 public 과 다를 바 없어요 .

항목 23: 멤버 함수보다는 비멤버 비프렌드 함수와 더 가까워지자

컴파일 의존도도 낮추고 객체 확장성이 커집니다 .

다른 클래스의 private 에 접근 가능한 함수의 개수를 늘리지 않으므로 캡슐화 짱짱맨 !

항목 23: 멤버 함수보다는 비멤버 비프렌드 함수와 더 가까워지자

헤더 안에 몰아서 네임스페이스로 묶자 -> 다른 요소의 컴파일 의존도를 낮춥니다 !

편의 함수 전체를 여러 개의 헤더 파일에 , 대신 하나의 네임스페이스에 넣으면 함수집합 확장도 쉬워져요

항목 24: 타입 변환이 모든 매개변수에 대해 적용되어야 한다면 비멤버 함수를 선언하자

비멤버 함수를 사랑합시다 .어떤 함수의 매개변수가 타입 변환을 필요로 한다면 , 비멤버 함수로 선언하는게 맞아요 .

멤버함수의 반댓말은 프렌드 함수가 아니라 비멤버 함수죠 !

항목 25: 예외를 던지지 않는 swap 에 대한 지원도 생각해 보자

내가 만든 타입에 대해 swap 멤버 함수를 제공해요 ! 예외는 던지지 말고요 .멤버 swap 이랑 비멤버 swap 같이 제공해요 .

std 는 마소 형님들 꺼니까 맘대로 추가하지 마세요 !