깊이있게 알아보자!

객체 배열의 힙 메모리 배치 구조.

상기와 같이 대다수의 컴파일러의 경우에는 객체 배열이 힙 메모리에 할당되면 맨 앞에 배열의 크기 정보가 함께 배치된다.

이 때문에, delete 연산자는 소멸자가 몇 번 호출될지를 쉽게 알 수 있게된다.

즉, []delete는 앞쪽의 배열 크기를 읽고, 배열 크기에 해당하는 횟수만큼 소멸자를 호출하게 된다.

만약 delete를 사용하게되면 그냥 단일 객체라 간주하고 소멸자 호출 횟수가 부족해져 메모리 누수가 발생할 것이다.

반대로 위와 같이 단일 객체를 해제하려고 할 때, []delete 연산자를 사용한다면... []delete 연산자는 stringObject 객체 메모리 앞쪽의

몇 바이트를 읽어 배열 크기라고 해석할 것이다. 그리고 배열 크기만큼 소멸자를 호출할텐데 결국 엉뚱한 메모리를 해제하려 할테고

알 수 없는 동작이 진행될 것이다.

그러므로 new 연산자에 []를 썼으면, delete 연산자에도 []를 써야 한다는 간단한 규칙만 생각해두면 된다.

또한 typedef로 정의된 어떤 타입의 배열을 생성하려고 new를 썼다면 delete 또한 []를 잊지 말아야 한다.

위의 예제와 같이 typedef를 사용한 경우도 결국 배열이다.
그러나 저렇게 배열 타입이 눈에 명확하게 보이지 않기 때문에, 배열 타입을 typedef 타입으로 만들지 않는 것이 좋다.

1줄 요약

 - new 표현식에 []를 썼으면, 대응되는 delete 표현식에도 []를 쓰자.
   마찬가지로 new 표현식에 []를 안 썼으면, 대응되는 delete 표현식에도 []를 쓰지 말자.

자원 관리 클래스는 실수로 터질 수 있는 자원 누출을 튼튼히 막아 주는 보호벽 역할을 해준다.
그러나 이미 많이 사용하고 있는 API들이 직접 참조하도록 만들어져 있어서, 자원 관리 객체의 보호벽을 슬그머니 넘어가

실제 자원을 직접 조작해야 할 일이 있다.

13장에서 작성했던 Investment 예제를 사용해서 shared_ptr을 통해 Investment 객체를 가리킨다고 하자.

위와 같이 dayHeld라는 Investment* 타입의 매개변수를 가진 함수에 스마트 포인터 객체를 전달한다면 컴파일 에러가 발생한다.

이유는 dayHeld 함수는 Investment* 타입의 실제 포인터를 원하는데, tr1::shared_ptr<Investment> 타입의 객체를 넘겨주었기

때문이다. 

사정이 이렇다 보니, RAII 클래스(shared_ptr)의 객체를 그 객체가 감싸고 있는 실제 자원(Investment*)으로 변환해주어야 한다.

변환할 방법으로는 명시적 변환(explicit conversion)과 암시적 변환(implicit convension)이 있다.

tr1::shared_ptr과 auto_ptr은 명시적 변환을 수행하는데 get이라는 멤버 함수를 통해 실제 자원을 얻어낼 수 있다.

RAII 객체 안에 들어 있는 실제 자원에 대한 접근을 매끄럽게 할 수 있도록 암시적 변환을 제공하는 설계자들도 있다.

FontHand의 규모가 무척 크다고 가정하면, Font 객체를 FontHandle로 변환해야 할 경우도 무척 많을 것이다.

그래서 Font 클래스에서는 이를 위한 명시적 변환 함수로 get을 제공하도록 만들 수 있다.

<명시적 형변환 추가.>

그런데 저렇게 자주 변형을 해줘야하는 경우에 사용자는 변환할 때마다 get을 호출해줘야 하기 때문에 짜증이나 Font 클래스를

사용하지 않게 될 수 있다. 그래서 FontHandle로의 암시적 변환 함수를 Font에서 제공하도록 한다.

<암시적 형변환 추가>

암시적으로 변환이 되기 때문에 매끄럽게 사용하기는 좋지만 진짜 Font를 쓰려고 한 부분에서 원하지 않게 FontHandle로 바뀔 수 있다.

이렇게 되면 Font 객체인 f1이 관리하고 있는 Fonthandle이 f2를 통해서도 직접 사용할 수 있는 상태가 된다.

하나의 자원이 양다리를 걸치고 있는 상황은 좋지 않다. 특히 f1이 소멸되버리면 f2는 해제된 폰트를 가리키고 있는 꼴이 된다.

RAII 클래스를 실제 자원으로 바꾸는 방법은 특정한 용도와 사용 환경에 따라 달라지는데, 어쨌든 가장 잘 설계된 클래스라면 뒤에서 배울

맞게 쓰기에는 쉽고, 틀리게 쓰기에는 어려워야 한다.

항상 그런것은 아니지만 명시적 변환을 제공하는 쪽이 나을 때가 많다. 그러나 암시적 변환에서 생기는 사용 시의 자연스러움이 빛을 발하는

경우도 있다.

2줄 요약

 - 실제 자원을 직접 접근해야 하는 기존 API들도 많기 때문에, RAII 클래스를 만들 때는 그 클래스가 관리하는 자원을 얻을 수 있는 방법을

   열어주어야 한다.

 - 자원 접근은 명시적 변환과 암시적 변환이 있는데, 안정성만 따진다면 명시적 변환이 대체적으로 더 낫지만, 고객 편의성을 놓고 보면

   암시적 변환이 괜찮다. (즉, 스스로 잘 판단해서 만들어라.)

힙 기반 자원에 대해서 auto_ptr과 tr1::shared_ptr 클래스로 관리하는 내용을 알아봤었다.
그러나 모든 자원은 힙에서 생기지 않고 힙에 생기지 않는 자원을 스마트 포인터로 처리해주는 것 또한 말이 되지 않는다.
항상 그런 것은 아니지만 자원 관리 클래스를 스스로 만들어야 할 필요를 느끼는 경우들이 있다.

예를 들어 Mutex 타입의 뮤텍스 객체를 조작하는 C API를 사용하는 중이라고 가정해보자.
C API에서 제공하는 함수 중엔 lock 및 unlock이 있다.

그런데 뮤텍스 잠금을 관리하는 클래스를 하나 만들고 싶은데 이는 뮤텍스 잠금을 잊지 않고 풀어 주고싶기 때문이다.
이런 용도의 클래스는 기본적으로 RAII 버칙을 따라 구성한다. 즉, 생성 시에 자원을 획득하고 소멸 시에 자원을 해제하는 것이다.

사용자는 이제 Lock을 사용할 때 RAII 방식에 맞춰 사용하면 된다.

여기까지 보면 문제가 없을 것 같지만 만약 Lock 객체가 복사가 된다면 어떤 동작이 이루어져야 할지 생각해봐야 한다.

선택 1 : 복사를 금지한다.

 RAII 객체가 복사되도록 놔두는 것 자체가 말이 안되는 경우가 꽤 많다.
 앞에 항목6에서 했던 것처럼 복사 연산을 private 멤버로 만들어준다.

선택 2 : 관리하고 있는 자원에 대해 참조 카운팅을 수행한다.

 자원을 사용하고 있는 마지막 객체가 소멸될 때까지 자원을 해제시키지 않아야하는 경우도 종종 있다.
 그렇다면 자신의 자원 관리 클래스에 참조 카운팅 방식의 복사 동작을 넣고 싶을 때, tr1::shared_ptr을 데이터 멤버로 넣으면

 간단히 해결될 것이다. 즉, Lock이 참조 카운팅 방식으로 돌아가면 좋을 것 같다고 생각하여 m_pMutex의 타입을 Mutex*에서

 tr1::shared_ptr<Mutex>로 바꾸라는 것이다. 그러나 아쉽게도 tr1::shared_ptr은 참조 카운트가 0이 될 때 자신이 가리키는 객체를

 삭제해 버리도록 되어있다. 내가 원한 것은 Mutex를 다 썼을 때 잠금만 해제하는 것이지 삭제까지는 하고 싶은 것은 아니였다.

 다행히도 tr1::shared_ptr이 '삭제자' 지정을 허용한다는 점이다. 삭제자란, tr1::shared_ptr이 유지하는 참조 카운트가 0이 되었을 때

 호출되는 함수 혹은 함수 객체를 말한다. (auto_ptr은 삭제자 기능 없음.)

 삭제자는 tr1::shared_ptr 생성자의 두 번째 매개변수로 선택적으로 넣어 줄 수 있다.

 그래서 하기와 같은 클래스 형태로 변경될 수 있다.

 여기서 특이한 점은 Lock 클래스의 소멸자가 없어졌다는 점이다. 이유는 필요 없기 때문이다.

 항목5에서 얘기했듯이 클래스의 소멸자는 비정적 멤버 변수들의 소멸자를 자동으로 호출해준다.

 m_pMutex 스마트 포인터도 비정적 멤버 변수이기 때문에 Lock 객체가 소멸될 때 자동으로 소멸이 된다.

 즉, m_pMutex는 참조 카운트가 0이 되면 소멸되는 것이 아니라 삭제자로 지정된 unlock 함수를 호출하여

 Mutex 잠금을 해제하고 나서 해당 Lock 객체가 소멸될 때에 비로서 Mutex 멤버 변수는 해제되는 것이다.

 여기서 주의할 점

 만약 외부에서 다른 shared_ptr 포인터가 mutex를 참조하고 있다면 어떻게 되는 것일까??

 하기 주석 참고...

선택 3 : 관리하고 있는 자원을 진짜로 복사한다.

 때에 따라서는 자원을 원하는 대로 복사할 수도 있다. 이때는 자원을 다 썼을 때 각각의 사본을 확실히 해제해줘야 한다.
 자원 관리 객체를 복사하면 이 객체가 관리하는 자원까지 모두 복사가 되어야 한다.
 즉, 깊은 복사를 수행해야 한다는 이야기이다.

선택 4 : 관리하고 있는 자원의 소유권을 옮긴다.

 흔한 경우는 아니지만, 특정원 자원에 대해 실제로 참조하는 RAII 객체가 딱 하나만 존재하도록 만들고 싶다면,

 객체가 복사될 때 그 자원의 소유권을 사본 쪽으로 아예 옮겨야 한다. auto_ptr이 바로 이런 방식이다.

2줄 요약

 - RAII 객체의 복사는 그 객체가 관리하는 자원의 복사 문제를 안고 가기 때문에, 그 자원을 어떻게 복사하느냐에 따라 RAII 객체의
   복사 동작이 결정된다.

 - RAII 클래스에 구현하는 일반적인 복사 동작은 복사를 금지하거나 참조 카운팅을 해 주는 선으로 마무리하는 것이다.

   하지만 이 외의 방법들도 가능하니 참고하자.

투자를 모델링해주는 클래스 라이브러리를 가지고 어떤 작업을 한다고 가정하자.

createInvestment 함수를 통해 객체를 얻기 때문에 사용자가 직접 객체를 해제시켜줘야 한다.

그러나 pInv를 가지고 처리를 하는 도중 문제가 발생하여 delete 부분에 도달하지 않고 함수를 빠져나가거나

사용자가 실수로 delete 구문을 빼먹을 수도 있다.
createInvestment 함수로 얻어낸 자원이 항상 해제되도록 만들 방법은 객체가 소멸될 때 소멸자에서 메모리를

해제시키는 방법이다.

표준 라이브러리를 보면 auto_ptr이라는 것이 있는데 auto_ptr은 포인터와 비슷하게 동작하는 객체(스마트 포인터)로서,

가리키고 있는 대상에 대해 소멸자가 자동으로 delete를 불러주도록 설계되어 있다.

자원 관리에 객체를 사용하는 방법의 중요한 두 가지 특징이 있다.

1. 자원을 획득한 후에 자원 관리 객체에게 넘긴다.

 상기 예제를 보면, createInvestment 함수가 만들어준 자원은 그 자원을 관리할 auto_ptr 객체를 초기화하는 데 쓰이고 있다.
 실제로, 이렇게 자원 관리에 객체를 사용하는 아이디어에 대한 용어도 자주 통용되는데 '자원 획득 즉 초기화' (RAII)라 부른다.

2. 자원 관리 객체는 자신의 소멸자를 사용해서 자원이 확실히 해제되도록 한다.

 소멸자는 어떤 객체가 소멸될 때 자동적으로 호출되기 때문에, 실행 제어가 어떤 경위로 블록을 떠나는가에 상관없이 자원 해제가

 제대로 이루어지게 된다.

auto_ptr은 자신이 소멸될 때 자신이 가리키고 있는 대상에 대해 자동으로 delete를 하기 때문에, auto_ptr은 오직 1개의 객체만

가리키는 것이 가능하다. 그래서 auto_ptr을 이용해서 객체를 복사하면 원본 객체는 null이 되버린다.

이러한 특성때문에, STL 컨테이너의 경우에는 원소들이 '정상적인' 복사 동작을 가져야 하기 때문에, auto_ptr은 STL 컨테이너들의

원소로 허용되지 않는다.

auto_ptr을 쓸 수 없는 상황이라면, 그 대안으로 참조 카운팅 방식 스마트 포인터(RCSP)를 사용하면 좋다.

RCSP는 특정 자원을 가리키는 외부 객체의 개수를 유지하고 있다가 그 개수가 0이 되면 해당 자원을 자동으로 해제시킨다.
마치 가비지 컬렉션과 비슷해보이지만, 참조 상태가 고리를 이루는 경우(예로 서로 다른 두 객체가 서로를 가리키는 경우)에는

자원을 해제시킬수 없다는 점은 가비지 컬렉션과 다르다.

tr1::shared_ptr을 사용하기 위해서는 VS2008 sp1 이상이여야 하며, #include <Memory>를 선언해줘야 한다.

auto_ptr, tr1::shared_ptr은 자원 관리를 하는 몇 가지 방법들 중 하나일 뿐 중요한 점은 자원 관리 객체를 사용해서 자원을

관리하는 것이 중요하다는 것이다.

알아둬야 할 점이 한 가지 더 있다. auto_ptr 및 tr1:shared_ptr은 소멸자 내부에서 delete 연산자를 사용한다.

delete[] 연산자가 아니다!! 즉, 동적으로 할당된 배열에 대해 auto_ptr이나 tr1::shared_ptr을 사용하면 절대 안된다는 것이다.

문제는 컴파일 에러도 발생하지 않는다는 점이다.

C++ 표준 라이브러리에서는 동적 할당된 배열을 위한 스마트 포인터가 제공되지 않는다.

이유는 동적으로 할당된 배열은 이제 vertor 및 string으로 거의 대체할 수 있기 때문이다.

2줄 요약

 - 자원 누출을 막기 위해, 생성자 안에서 자원을 획득하고 소멸자에서 그것을 해제하는 RAII 객체를 사용하자.

 - 일반적으로 RAIi 클래스는 tr1::shared_ptr과 auto_ptr이 있다. tr1::shared_ptr이 복사 시의 동작이 직관적이기 때문에

   사용하기 더 좋다. auto_ptr은 복사되는 객체를 null로 만들어 버린다.

캡슐화한 객체 지향 시스템 중 설계가 잘 된 것들을 보면, 객체를 복사하는 함수가 딱 둘만 있는 것을 알 수 있다.

복사 생성자와 복사 대입 연산자인데 이 둘을 통틀어 복사 함수라고 한다.

문제될 것이 없는 코드이지만 멤버 변수 하나를 추가하면서 문제가 발생한다.
기존에 작성된 코드에서 멤버 변수가 추가됨에 따라 생성자, 복사생성자, 복사 대입 연산자 모두를 수정해야한다.
혹여나 여기서 하나라도 빼먹게되면 부분 복사가 되버리게 된다.
특히, 상속 관계에서는 더욱 더 신경써줘야 한다.

겉으로 보기에는 모든 정보를 복사하고 있는 것처럼 보이지만, 그렇지 않다.
PriorityCustomer에 선언된 데이터는 모두 복사하고 있는 것은 맞지만, 부모 class인 Customer로부터 상속한 데이터 멤버들은

복사가 되지 않고 있다.
Customer의 데이터들도 엄연히 파생클래스인 PriorityCustomer에 들어있기 때문에 Customer의 데이터도 반드시 모두 복사해줘야 한다.
PriorityCustomer의 복사 생성자에는 기본 클래스 생성자에 넘길 인자들도 명시되어 있지 않아서 PriorityCustomer형 객체의 Customer 부분은

인자없이 실행되는 Customer 기본 생성자에 의해 기본적인 초기화만 된다.

또한 PriorityCustomer의 복사 대입 연산자의 경우에는 기본 클래스의 데이터 멤버를 건드릴 시도도 하지 않기 때문에,

기본 클래스의 데이터 멤버는 변경되지 않고 그래로 있게 된다.

즉, 파생 클래스에 대한 복사 함수를 직접 만든다면 기본 클래스 부분을 복사에서 빠뜨리지 않도록 주의해야 한다.
기본 클래스의 멤버 변수들은 private일 가능성이 높으므로 직접 접근하기 어렵다.

그러므로 파생 클래스의 복사 함수 안에서 기본 클래스의 복사 함수를 호출하도록 만들어서 사용하면 된다.

또한 복사 생성자와 복사 대입 연산자의 동작은 비슷하므로 함수 본문 또한 비슷하다.
그래서 아마도 코드 중복을 피하려고 한쪽에서 다른 한쪽을 호출하는 것을 생각할 수 있는데…. 절대 그래선 안된다.
(대입 연산자에서 복사생성자를 호출한다던지 복사생성자에서 대입 연사자를 호출한다던지)

복사 대입 연산자는 이미 생성된 객체에서만 사용이 가능한데 복사 대입 연산자에서 복사 생성자를 호출하면 이미 존재하는

객체를 또 만들려는 동작이 되버린다. (이미 태어난 아이에게 엄마 뱃속으로 들어가라는 꼴임)

헷갈릴까봐 적는거지만 생성과 동시에 = 를 이용해서 대입하면 복사 대입 연산자가 아닌 복사 생성자가 호출된다.

즉, 복사 대입 연산자는 이미 생성된 객체에서만 사용 가능하다는 의미이다.

거꾸로 복사 생성자에서 복사 대입 연산자를 호출한다는 것 또한 말이 되지 않는다.

대입 연산자의 의미는 이미 초기화가 끝난 객체에게 값을 주는 것인데 아직 초기화가 완료되지 않은 객체에 대입을 하게되므로

프로그램이 죽을 수도 있다.

하고 싶다면 별도의 private 함수를 만들어서 각 함수에서 호출하도록 하자.

2줄 요약

 - 객체 복사 함수는 주어진 객체의 모든 데이터 및 모든 기본 클래스 부분을 빠뜨리지 말고 복사해라.

 - 클래스의 복사 함수 두 개를 구현할 때, 한쪽을 이용해서 다른 쪽을 구현하려는 시도는 절대하지 마라.

자기 대입이란 어떤 객체가 자기 자신에게 대입 연산자를 적용하는 것을 말한다.

이러한 자기 대입이 생기는 이유는 여러 곳에서 하나의 객체를 참조하는 상태인 중복참조 때문이다.

같은 타입으로 만들어진 객체 여러 개를 참조자 혹은 포인터로 물어 놓고 동작하는 코드를 작성할 때는

같은 객체가 사용될 가능성을 고려하는 것이 좋다.

특히 자원 관리와 엮여있는 경우에는 더욱 더 주의해야 한다.

상기와 같이 작성된 코드에서 자기 대입이 진행된다면, 좌변 객체(this)와 우변 객체(rhs)가 동일하므로 멤버 변수인 pb 또한

this의 것이기도 하면서 rhs의 것이기도 하다.

사용자의 의도는 원래 pb를 제거하고 다시 새로운 정보를 가지고 pb를 생성하려고 했던 것인데...

bp를 제거함으로써 this의 pb 뿐만 아니라 초기화 재료로 사용하려던 rhs의 pb 또한 제거가 된다.

그러므로 결국 operator= 함수에서 새로 생성되는 pb는 쓰레기 값을 가진 Data가 된다. (아니면 null이 되어 null exception 발생)

해결 방법 1

전통적인 방법으로 operator=의 첫머리에 일치성 검사를 통해 자기대입을 검사한다.

그러나 이 방법은 예외에는 안전하지 않다.

무슨 말이냐하면, new Bitmap 부분에서 예외가 터지게 되면 (동적 할당에 필요한 메모리 부족, 복사 생성자에서

예외 발생 등...), Widget 객체는 삭제된 Bitmap을 가리키는 포인터를 껴안고 남게된다.

즉, 아무것도 가리키지 않는 포인터가 하나 남게되고 이것을 delete 시켜줄 방법 또한 없다.

또한 if문으로 조건 처리하는데 속도 저하에도 영향을 미칠 수 있다.

해결 방법 2.

대입 연산은 여러 개가 사슬처럼 엮일 수 있고 우측 연관 연산이라는 특징이 있다.

이렇게 대입 연산이 사슬처럼 엮이려면 대입 연산자가 좌변 인자에 대한 참조자를 반환하도록 구현되어 있을 것 이다.

이런 구현은 일종의 관례인데, 사용자가 직접 구현하는 클래스에 대입 연산자가 들어간다면 이 관례를 지키는 것이 좋다.

"좌변 객체의 참조자를 반환하게 만들자"라는 규약은 모든 형태의 대입 연산자에서 지켜져야 한다.

이 관례는 모든 기본 제공 타입들이 따르고 있고 표준 라이브러리에 속한 모든 타입들에서도 따르고 있다.

따르지 않더라도 컴파일이 안되거나 그런건 아니지만 관례는 그냥 따르는게 좋다.

* 주의 사항

<예시>

Transaction 클래스는 추상 클래스이다.

BuyTransaction, SellTransaction 클래스는 Transaction 클래스로부터 상속을 받았다.

main 함수에서 BuyTransaction 타입의 변수를 선언했다.

그렇다면 무엇이 문제의 소지가 되는 것일까??

상속 관계에서 생성자는 가장 위의 부모 클래스에서부터 맨 마지막 자식 클래스까지 순차적으로 호출된다.

그러면 BuyTransaction 타입의 buy 변수가 생성될 때는 Transaction 클래스의 생성자가 가장 먼저 호출된다.

그런데 Transaction 클래스의 생성자에는 logTransaction()를 호출하는 문장이 있다. 문제는 여기서 발생한다.

기본 클래스의 생성자가 호출될 동안에는, 가상 함수는 절대로 파생 클래스 쪽으로 내려가지 않는다.

즉, 기본 클래스의 생성자에서 호출되는 logTransaction 함수는 BuyTransaction의 함수가 아니라 Transaction의 함수가 호출

되는 것이다.

이유는 기본 클래스의 생성자가 동작하는 시점에는 아직 파생 클래스의 데이터들은 초기화가 되어있지 않은 상태이기 때문이다.

만약 기본 클래스에서 호출한 가상 함수가 파생 클래스의 가상 함수를 호출하게 된다면 파생 클래스의 가상 함수에는 분명히

파생 클래스의 멤버 변수들을 사용하는 문장들이 있을텐데 아직 초기화되어 있지 않은 멤버들에 접근하는 것은 문제의 원인이 된다.

더 핵심적인 사실은 기본 클래스의 생성자가 동작하는 동안에는 선언한 변수 타입과 상관없이 기본 클래스 타입으로서 변경된다.

즉, BuyTransaction 타입으로 변수를 생성하였다 하더라도 기본 클래스 부분은 초기화하기 위해 Transaction 생성자가 실행되는 동안은

Transaction 타입으로 선언된 것 마냥 동작된다는 것이다.

파생 클래스의 데이터가 아직 초기화가 되지 않은 상태이므로 아예 없었던 것처럼 취급하는 편이 가장 안전하기 때문이다.

소멸자 또한 마찬가지이다.

파생 클래스의 소멸자가 호출되고 나면 파생 클래스의 데이터 멤버는 정의되지 않은 값으로 가정하기 때문에.

c++는 이들을 없는 것처럼 취급하고 진행한다. 기본 클래스 소멸자에 진입할 당시의 객체는 기본 클래스 객체가 된다.

해결 방법

1. logTransaction을 Transaction 클래스의 비가상 멤버 함수로 변경.

2. 파생 클래스의 생성자들로 하여금 필요한 로그 정보를 Transaction의 생성자로 넘기기.