프로그래밍 쉼터

C++에서는 함수로부터 객체를 전달받거나 함수에 객체를 전달할 때 '값에 의한 전달' 방식을 사용합니다.

함수 매개변수는 실제 인자의 사본을 통해 초기화되며, 어떤 함수를 호출한 쪽은 그함수가 반환한 값의 사본을 돌려 받습니다.

위의 내용처럼 사본을 만들어내는 원천이 바로 복사 생성자 입니다.

plato로부터 매개변수 s를 초기화시키기 위해 Student의 복사 생성자가 호출된다. s는 ValidateStudent가 복귀할 때 소멸된다. Student 객체가 생성될 때마다 string 멤버도 생성된다. 게다가 Student 객체는 Person 객체로부터 파생되었기 때문에, Student 객체의 생성자가 호출되기 이전에 Person 객체가 생성된다. Person 객체가 생성될 때에도 string 멤버도 생성된다.

bool ValidateStudent( const Student& s ); //참조의 의한 전달 방식으로 바꾸기만 하면 됩니다. 

이렇게 할 경우,

우선 새로 만들어지는 객체라는 것이 없으므로 생성자/소멸자가 호출되지 않는다.

그리고 const를 붙임으로써 전달인자로 보낸 객체가 함수에 의해 변하지 않는다는 것을 명시해준다. 원래 값에 의한 전달 방식때도 원본 객체는 보호되는데 그 의미를 그대로 적용한 것이라고 보면 됩니다.

또한, '복사 손실' 문제도 없어집니다. 아래의 코드를 봅시다.

C++에서 새로운 클래스를 정의 한다는 것은 새로운 타입을 하나 정의하는 것과 같습니다. 

어떤 인터페이스를 어떻게 써 봤는데 결과 코드가 사용자가 생각한 대로 동작하지 않는다면, 그 코드는 컴파일 되지 않아야 맞습니다. 거꾸로 생각해서, 어떤 코드가 컴파일 된다면 그 코드는 사용자가 원하는 대로 동작해야할 것입니다.

'제대로 쓰기에 쉽고, 엉터리로 쓰기에 어려운' 인터페이스를 개발 하려면?

우선 사용자가 저지를 만한 실수의 종류를 머리에 넣어 두고 있어야 합니다.  

위의 코드는 어찌보면, 문제될게 없어보이지만, 사용자가 쉽게 실수를 저지를수 있습니다.

위의 주석대로 매개변수의 전달 순서가 잘못될 여지가 있습니다.

위의 문제는 간단한 랩퍼 타입을 각각 일, 월, 연을 만들고 이 타입을 Date 생성자 안에 두면, 어느정도 해결 됩니다.

위와 같이 적절한 타입만 제대로 준비되어 있으면, 각타입의 값에 제약을 가하더라도 괜찮은 경우가 생기게 됩니다.

예를 들어,

월이 가질 수 잇는 유효한 값은 12개이므로, Month 구조체 타입에 이 사실을 제약조건으로 부여할 수 있다.

사용자 실수로 예상되는 것중에 또 하나는 다음과 같은 경우가 있다

if( a * b = c ) ... // '='가 '=='가 되어야 맞다

기본적으로 우리는 int등의 타입이 어떻게 동작하는지 그 성질을 이미 다 알고 있기 때문에, 사용자를 위해 만드는 타입도 웬만하면 이들과 똑같이 동작하게 만드는 센스를 갖추어야 합니다.

이것은 일관성 있는 인터페이스를 제공하기 위해서입니다.

STL 컨테이너의 인터페이스는 전반적으로 완벽하진 않지만, 일관성을 갖고 있으며, 이때문에 사용하는데 큰 부담이 없습니다.

ex ) STL컨테이너 size() 멤버함수를 개방해 놓음

사용자 쪽에서는 뭔가를 외워야 제대로 쓸 수 있는 인터페이스는 잘못 쓰기 쉽습니다.

예를 들어,

이전 항목 13 에서 봤던 createInvestment() 팩토리 함수의 경우, 클래스 포인터를 반환한다.

함수에서 얻어낸 포인터는 동적 할당된 자원이기 때문에, 종료 전에 반드시 메모리를 해제해야한다.

사용자는 다음과 같은 실수를 저지를 수 있습니다.

1) 포인터 삭제를 잊어버렸다!

2) 같은 자원에 delete를 두번 해버렸다!!

이전 항목 13 에서는 이 문제를 해결하기 위해 스마트 포인터를 이용했다.

그러나 사용자는 스마트 포인터를 사용해야 한다는 사실을 모르면 어떻게 할까요?

그 해결책,

애초부터 팩토리 함수가 스마트 포인터를 반환하게 만드는 것입니다.

std::tr1::shared_ptr<Investment> createInvestment();

위와같은 방법으로 구현되면, 사용자는 무조건 해당 타입에 맞게 받아줘야합니다. 그렇지 않으면 에러가 납니다.

게다가 std::tr1::shared_ptr은 생성 시점에 자원 해제 함수(일명 삭제자)를 직접 엮을 수 있는 기능을 갖고 있기 때문에, 자원해제에 관련된 상당수의 사용자 실수를 사전 봉쇄할 수 있습니다.

또하나, std::tr1::shared_ptr은 '교차 DLL 문제'를 방지해준다.

서로 다른 DLL 사이에서 new와 delete를 했을 경우, 꼬여서 런타임 에러가 발생하는 것을 막아준다는 것입니다.

왜냐하면 기본 삭제자가 무조건 동일 DLL에서 이 짝을 수행할 수 있게 설계되어있기 때문이고, std::tr1::shared_ptr은 생성시에 그해당 DLL을 붙잡고 있기 때문입니다.

참고로, tr1::shared_ptr을 구현한 제품 중 가장 흔히 쓰이는 것은 Boost 라이브러리 입니다. 부스트의 shared_ptr은 일단 크기가 원시 포인터의 두배이고, 느리며, 내부 관리용 동적 메모리 까지 추가로 들지만, 사용자의 실수는 눈에 띄게 줄어들것입니다.

이것 만은 잊지 말자!

◆ 좋은 인터페이스는 제대로 쓰기에 쉬우며 엉터리로 쓰기에 어렵습니다. 인터페이스를 만들때는 이 특성을 지닐 수 있도록 고민하고 또 고민합시다.

◆ 인터페이스의 올바른 사용을 이끄는 방법으로는 인터페이스 사이의 일관성 잡아주기, 그리고 기본제공 타입과의 동작 호환성 유지하기가 있습니다.

◆ 사용자의 실수를 방지하는 방법으로는 새로운 타입 만들기, 타입에 대한 연산을 제한하기, 객체의 값에 대해 제약 걸기, 자원 관리 작업을 사용자 책임으로 놓지 않기가 있습니다.

◆ std::tr1::shared_ptr은 사용자 정의 삭제자를 지원합니다. 이 특징 때문에 std::tr1::shared_ptr은 교차 DLL 문제를 막아주며, 뮤텍스 등을 자동으로 잠금 해제하는데 쓸수 있습니다.

아래 코드를 보자

이 코드가 컴파일 에러가 나는 이유는 std::tr1::shared_ptr 의 생성자는 explicit 되어있기때문에 new Widget 같은 표현식이 올수 없다.

processWidget(std::tr1::shared_ptr<Widget>(new Widget), priority());

위의 코드는 컴파일에 문제가 없다.

하지만, 스마트 포인터로 받은 자원을 흘릴 가능성이 있는 함수다.

왜 그럴까?

C++함수는 함수를 호출할때 함수로 들어오는 인자의 평가 순서를 지니게 된다.

첫번째 인자는 (new Widget) 과 std::tr1::shared_ptr의 생성자 호출부분으로 나뉜다.

두번째 인자는 함수포인터로 함수의 호출문이 있다.

우선 위의 함수가 호출될때 컴파일러는 세가지 연산을 위한 코드를 만든다.

1. priority를 호출한다.

2. new widget 을 실행한다.

3. std::tr1::shared_ptr 생성자를 호출합니다.

이 연산이 실행되는 순서는 컴파일러 제작사마다 다르다.  

우선  std::tr1::shared_ptr은 new widget 이 실행되야지만, 실행되는 순서이다. 그렇기 때문에 순서가 변하지는 않지만, priority는 처음 호출될수도 있고, 두번째, 세번째도 호출될 수도 있습니다.

이때 2번과 3번 중간에 priority 함수가 호출되서 예외가 발생했다면, 자원을 막아줄줄 알고 준비한 std::tr1::shared_ptr에 저장되기도 전에 예외가 발생합니다.

위와같은 문제를 해결하기 위해서는?

어찌되었든 가장중요한 건!!

ProcessWidget 함수가 호출되기전에 Widget을 생성해서 스마트 포인터에 저장하는 코드를 별도의 한문장으로 하나 만들고, 그 스마트포인터를 넘기는 것입니다.

std::tr1::shared_ptr<Widget> pw( new Widget );

processWidget( pw, priority() );

이것 만은 잊지 말자!

◆ new로 생성한 객체를 스마트 포인터로 넣는 코드는 별도의 한 문장으로 만듭시다. 이것이 안되어 있으면, 예외가 발생될 때 디버깅하기 힘든 자원 누출이 초래될 수 있습니다.

메모리 할당의 순서(new)

1) 메모리 할당

2) 할당된 메모리에 대해 한 개 이상의 생성자 호출

메모리 해제의 순서(delete)

1) 할당된 메모리에 대해 한 개 이상의 소멸자 호출

2) 메모리 해제

배열을 위해 만들어지는 힙 메모리에는 대개 배열원소의 개수가 박혀 들어갑니다.

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

int *i = new int[5];

delete i;

int형의 공간 다섯개만큼의 메모리를 할당했지만,delete는 단일 객체만을 해제한다고 표시했기 때문에,

메모리가 모두 해제되지 못합니다.

typedef로 정의된 어떤타입의 객체를 메모리에 생성하는것은 주의를 해야한다.

왜냐하면?

typedef std::string AddressLines[4];  // AddressLine으로 정의하고

std::string *pal = new AddressLines; // 이렇게 생성하게 되면 나중에 명확하지 않아 혼동될수 있습니다. 배열타입을 typedef 타입으로 만들지 않는 것이 좋습니다. ( vector<string> 사용 합시다 )

즉! 

new -> delete 씁시다. 

new [] -> delete[] 씁시다.

우리가 스마트포인터를 이용하여 객체를 관리할때

즉!

std::tr1::shared_ptr<Investment> pInv( createInvestment() );  

위와 같이 스마트 포이터를 선언하고, Investment 클래스를 사용하는 함수를 만들려고 할 때, 

int daysHeld(const Investment *pi);

이렇게 선언한 뒤

int days = daysHeld(pInv);

이렇게 사용하는 것이 일반적일 것이다. 그러나 이 구문은 에러가 난다.

왜냐하면 daysHeld의 전달인자는 Investment의 포인터형이지만, pInv는 std::tr1::shared_ptr<Investment> 타입의 객체이기 때문에 타입이 맞지 않아 에러가 발생하는 것이다. 

그래서,

스마트 포인터가 가리키는 실제 자원으로 변환해야 할 필요가 있는데, 여기서 방법은 명시적 변환과 암시적 변환이 있다.

첫째, 명시적 변환 

std::auto_ptr와 std::tr1::shared_ptr에는 실제 포인터를 명시적으로 얻을 수 있는 get()멤버함수를 제공한다. 

둘째, 암시적 변환

std::auto_ptr와 std::tr1::shared_ptr에는 자신이 관리하는 실제 포인터에 대한 암시적 변환도 쉽게 얻을 수 있게 operator-> 와 operator* 을 정의해 두었습니다.

( ex. 사용예 pi->isEmpty(), *(pi).isEmpty() 드러나 있지 않지만 변환이 실제 포인터로 변환이 이루어진 상태에서 자원에 접근 하고 있다. ) 

또한, 암시적 변환 함수를 이용해서 스마트 포인터 변수명만으로도 실제 포인터를 얻어낼수 있습니다.

operator 변환될 자료형 () const; ( ex. operator FontHandle() const { return f; } )

위의 변환을 사용하게 되면, 암시적으로 쉽게 내부 포인터를 얻어 올수 있게 되지만, 원하지 않는 변환이 일어 날 수도 있기때문에 조심해야한다.

꼼꼼히 제대로 설계된 클래스가 그렇듯, 사용자가 볼 필요가 없는 데이터는 가리지만 고객 차원에서 꼭 접근해야 하는 데이터는 열어 주는 것입니다.

이것 만은 잊지 말자!

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

자원은 모두 Heap에서 생성되는 것은 아니기 때문에 동적 할당 객체가 아닌경우에는 스마트 포인터가 적절하지 않습니다.

이와 같은경우 사용자가 직접 자원관리 클래스를 만들어줘야 합니다.

다음과 같이 RAII 법칙을 따라 클래스를 구성합니다.

이러한 RAII클래스를 구현했지만, 문제는 RAII 객체가 복사될때는 어떤 동작을 이루어져야 하는지가 참 힘들게 합니다. 실제로 RAII 클래스는 복사되도록 놔두는 것 자체가 말이 안되는 경우가 꽤 많습니다.

자 그럼 복사에 대한 문제해결을 하기위한 방법을 알아봅시다.

첫째, 복사를 금지합니다.  

복사하면 안되는 RAII클래스에 대해서는 반드시 복사가 되지 않도록 막아야 합니다. 사본이 필요없는경우 입니다. 위의 예제도 이 부류에 속합니다.( Uncopyable 클래스를 사용 )

둘째, 관리하고 있는 자원에 대해 참조 카운팅을 수행합니다.  

std::shared_ptr을 이용하여 참조하는 객체의 갯수가 0이 될때 그지정한 객체를 삭제시킵니다.

하지만, 위의 클래스의 예를 들자면 우리는 Mutex는 삭제가 아니고 ulock만을 원합니다.

이럴땐 std::shared_ptr의 생성자중에 삭제자를 지정할 수있는 생성자를 사용합니다.

삭제자란? tr1::shared_ptr이 유지하는 참조 카운트가 0이 되었을 때 호출되는 함수 혹은 함수 객체를 일컷습니다.

셋째, 관리하고 있는 자원을 진짜로 복사합니다.( deep copy )  

 자원의 깊은 복사를 수행하는 것입니다.( ex. std::string 타입의 복사 방식 ) 

넷째, 관리하고 있는 자원의 소유권을 옮깁니다. 

std::auto_ptr 처럼 소유권은 단 한개만 가지고 싶을경우

이것 만은 잊지 말자!

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

◆ RAII 클래스에 구현하는 일반적인 복사 동작은 복사를 금지하거나 참조 카운팅을 해 주는 선으로 마무리 하는 것입니다. 하지만 이 외의 방법들도 가능하니 참고해 둡시다. 

아래의 예제를 봅시다.

createInvestment() 함수를 통해 Investment 클래스의 포인터를 가져와서, pInv의 어떠한 동작을 수행한뒤, pInv의 메모리를 해제 합니다. 

정상적인 수행을 하게되면, 당연히도 delete pInv; 까지 내려가서 수행후 함수호출을 빠져나오는것을 생각하지만, 여기에선 return 문을 만나 바로 함수호출을 빠져 나간다든지, 많은 예외가 있습니다. 즉 ! 메모리 누수가 발생하게 됩니다.

우리는 createInvestment() 함수로 얻어낸 자원이 항상 해제되도록 만들어야 합니다. 그러기위해서는 자원을 객체에 넣고 그 자원 해제를 소멸자가 맡도록 하며, 그 소멸자는 실행 제어가 function()함수를 떠날 때 호출되도록 만드는 것입니다.

표준라이브러리를 보면 auto_ptr이 있는데 위에있는 용도에 쓰라고 마련된 클래스입니다.

std::auto_ptr< 생성할 클래스 > 변수명( 동적할당된 포인터 )

이렇게 자원을 획득(동적할당)한후 바로 자원 관리 객체에게 넘겨주는데, 자원 획득 하자마자 초기화 하는 이러한 방법을 RAII(Resource Acquisition is Initialization) 이라고 합니다.

std::auto_ptr 은 자신이 소멸될 때 자신이 가리키고 있는 대상에 대해 자동으로 delete를 수행합니다.

그렇기 때문에 어떤 객체를 가리키는 auto_ptr의 개수가 둘 이상이면 절대로 안됩니다. 만약에 이런사태가 벌어지면 결국 자원이 두번 삭제 될테니 큰 문제가 됩니다.

위와같은 문제 때문에 std::auto_ptr은 객체를 복사하면, 원본 객체는 NULL로 만듭니다. 복사하는 객체만이 그 자원의 유일한 소유권을 갖는다고 가정합니다.

여러번 할당해제되는 문제를 막을 수 있지만, 정상적인 복사 동작을 요구하는 STL컨테이너에서는 auto_ptr 객체를 원소로서 허용하지 않습니다.

그래서 그 대안으로 참조 카운팅 방식 스마트 포인터 (reference-counting smart pointer: RCSP)가 있다. RCSP는 특정한 어떤 자원을 가리키는 외부 객체의 개수를 유지하고 있다가 그 개수가 0이 되면 해당 자원을 자동으로 삭제하는 스마트 포인터 입니다.

어떤 함수내에서 shared_ptr을 이용해서 객체를 사용하고 나면 여러개의 shared_ptr이 같은 객체를 참조 하고 있다하더라도 함수가 끝나면서 지역변수였던 모든 shared_ptr을 해제 하기 때문에 자연스럽게 동적할당된 자원이 반환되게 됩니다.

이렇듯, 스마트 포인터는 아주 중요한 부분이며, 자원관리에 효율적입니다.

하지만 이러한 스마트 포인터의 소멸자에 있는 delete 연산자는 delete [] 연산자가 아닙니다.

즉!

스마트 포인터 인자로 배열을 받으면 안된다는 것입니다.

std::auto_ptr<int> num( new int[10] ); // 문제가 발생합니다. 배열을 쓰면 안됩니다.

배열에 쓸수 있는 auto_ptr이라든지 tr1::shared_ptr을 원한다면, Boost라이브러리에 있는

boost::scoped_array와 boost::shared_array를 알아 보면 됩니다.

이것 만은 잊지 말자!

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

◆ 일반적으로 널리 쓰이는 RAII 클래스는 tr1::shared_ptr 그리고 auto_ptr 입니다.

이 둘 가운데 tr1::shared_ptr이 복사 시의 동작이 직관적이기 때문에 대개 더 좋습니다. 반면, auto_ptr은 복사되는 객체(원본 객체)를 NULL로 만들어 버립니다.