MoreEffectiveC++/Techniques1of3 - Revision history

Maintenance script: Repair MoniWiki formatting after migration

2026-03-29T00:34:26Z

Repair MoniWiki formatting after migration

← Older revision		Revision as of 00:34, 29 March 2026
Line 265:		Line 265:
	'''첫번째'''로 만들어지는 객체의 위치이다. 위의 제시된 두가지의 방법에서, Printer 정적(staitc) 객체가 하나는 friend로 클래스의 제어권을 획득한 함수 내부에 있고, 또 하나는 클래스 멤버 메소드 내부에 있다. 함수에 있는 경우에는 정적(static) 객체는 항상 만들어져 있다. 이 의미는 해당 코드의 프로그램이 시작될때 부터 아예 객체가 만들어 진다는 의미이다. 즉, 한번도 그 객체를 사용하지 않아도, 객체는 이미 만들어져 비용을 지출하게 한다. 반면에, 함수 멤버 메소드 내부에 정적(static)객체를 만들 후자의 경우에는 객체를 만드는 역할을 하는 메소드인 Printer::thePrinter 가 제일 처음 호출될때 객체가 생성된다. 이것은 C++에서 "사용하지 않는 객체에 대한 비용은 지불하지 않는다."의 설계 다소 복잡한 이념에 근간을 둔 개념이다. 그리고 이러한 복잡한 개념은 당신을 해깔리게 만든다.		'''첫번째'''로 만들어지는 객체의 위치이다. 위의 제시된 두가지의 방법에서, Printer 정적(staitc) 객체가 하나는 friend로 클래스의 제어권을 획득한 함수 내부에 있고, 또 하나는 클래스 멤버 메소드 내부에 있다. 함수에 있는 경우에는 정적(static) 객체는 항상 만들어져 있다. 이 의미는 해당 코드의 프로그램이 시작될때 부터 아예 객체가 만들어 진다는 의미이다. 즉, 한번도 그 객체를 사용하지 않아도, 객체는 이미 만들어져 비용을 지출하게 한다. 반면에, 함수 멤버 메소드 내부에 정적(static)객체를 만들 후자의 경우에는 객체를 만드는 역할을 하는 메소드인 Printer::thePrinter 가 제일 처음 호출될때 객체가 생성된다. 이것은 C++에서 "사용하지 않는 객체에 대한 비용은 지불하지 않는다."의 설계 다소 복잡한 이념에 근간을 둔 개념이다. 그리고 이러한 복잡한 개념은 당신을 해깔리게 만든다.

	( DeleteMe Translation unit의 해석이 불분명하다.)		( [[DeleteMe]] Translation unit의 해석이 불분명하다.)
	또 이 둘의 다른 취약점은 초기화 되는 시간이다. 우리는 함수의 경우에 초기화 시간을 정확히 알수 있다. 아예 처음 이니까 하지만 멤버 메소드로 구현시에는 모호하다. C++는 확실히 특별하게 해석해야 할 부분(단일 객체에서 소스 코드 몸체 부분 따위)은 정적 인자들에 대한 초기화 순서가 보장 된다. 하지만 서로 다른 해석 부분(translation unit)에 있는 정적 객체들의 초기화 순서에 대해서는 말할수가 없다. 이것은 머리를 아프게만 할뿐이다.		또 이 둘의 다른 취약점은 초기화 되는 시간이다. 우리는 함수의 경우에 초기화 시간을 정확히 알수 있다. 아예 처음 이니까 하지만 멤버 메소드로 구현시에는 모호하다. C++는 확실히 특별하게 해석해야 할 부분(단일 객체에서 소스 코드 몸체 부분 따위)은 정적 인자들에 대한 초기화 순서가 보장 된다. 하지만 서로 다른 해석 부분(translation unit)에 있는 정적 객체들의 초기화 순서에 대해서는 말할수가 없다. 이것은 머리를 아프게만 할뿐이다.

Line 274:		Line 274:
	return p;		return p;
	}		}
	다음과 같은 코드의 함수는 매우 짧다. 이런 짧은 함수는 함수보다 inline 시켜서 속도를 높이는 것이 더 효과적이다. 하지만 그럴수가 없다. 왜 그런가 하면, inline의 의미는 정확히 해당 함수가 쓰이는 코드를 현재 함수의 몸체로 교체해 버리는 역할이다. 그런게 이렇게 할경우, 위와 같은 함수는 static객체의 처리에서 의문이 생긴다. 해당 함수가 호출된 곳을 위와 같은 함수 몸체로 교체하면, 각 교체 부분은 전부 독립적인 static 인자를 부여 받는 셈이 되어 버린다. 그래서 정적 인자를 쓴 함수는 inline을 시키지 못하며, 이런 정적 인자의 사용에 따라 일어나는 의문을 internal linkage를 가진 문제 라고 한다. DeleteMe) 날림 요약 수정 필요		다음과 같은 코드의 함수는 매우 짧다. 이런 짧은 함수는 함수보다 inline 시켜서 속도를 높이는 것이 더 효과적이다. 하지만 그럴수가 없다. 왜 그런가 하면, inline의 의미는 정확히 해당 함수가 쓰이는 코드를 현재 함수의 몸체로 교체해 버리는 역할이다. 그런게 이렇게 할경우, 위와 같은 함수는 static객체의 처리에서 의문이 생긴다. 해당 함수가 호출된 곳을 위와 같은 함수 몸체로 교체하면, 각 교체 부분은 전부 독립적인 static 인자를 부여 받는 셈이 되어 버린다. 그래서 정적 인자를 쓴 함수는 inline을 시키지 못하며, 이런 정적 인자의 사용에 따라 일어나는 의문을 internal linkage를 가진 문제 라고 한다. [[DeleteMe]]) 날림 요약 수정 필요

	자, 똑똑한 사람 이라면 당연히, 지금까지의 코드에서 의문점과 문법에 대한 의아함을 일으 킬수 있다. thePrinter는 둘다 내부에 있는 static 객체의 참조를 반환하는데, 이 "static 객체는 해당 함수,메소드의 영역(scop) 내부에서 쓰여야지 외부에서 쓰이면 안되지 않는가?" 라는 의문이 그것이다. 즉, 클라이언트 입장에서 이들 객체는 숨겨져(hidden)있는 존재이고, 이것을 사용하는 것은 잘못된 방법이다. 라고 말할수 있겠는데, 그래서 아마 당신은 다음과 같이 객체의 숫자를 세고, 제한된 객체의 수보다 더 많은 객체를 사용시 예외를 발생시켜서 문제를 해결하는 것이 더 좋은 방법이라 말할 것이다.		자, 똑똑한 사람 이라면 당연히, 지금까지의 코드에서 의문점과 문법에 대한 의아함을 일으 킬수 있다. thePrinter는 둘다 내부에 있는 static 객체의 참조를 반환하는데, 이 "static 객체는 해당 함수,메소드의 영역(scop) 내부에서 쓰여야지 외부에서 쓰이면 안되지 않는가?" 라는 의문이 그것이다. 즉, 클라이언트 입장에서 이들 객체는 숨겨져(hidden)있는 존재이고, 이것을 사용하는 것은 잘못된 방법이다. 라고 말할수 있겠는데, 그래서 아마 당신은 다음과 같이 객체의 숫자를 세고, 제한된 객체의 수보다 더 많은 객체를 사용시 예외를 발생시켜서 문제를 해결하는 것이 더 좋은 방법이라 말할 것이다.
Line 560:		Line 560:
	template<class BeingCounted>		template<class BeingCounted>
	int Counted<BeingCounted>::numObjects; // 객체의 선언과, 자동으로 0으로 초기화가 된다.		int Counted<BeingCounted>::numObjects; // 객체의 선언과, 자동으로 0으로 초기화가 된다.
	DeleteMe) 이것이 되는 과정도 정확히 이해가 가지 않는다. 되는거였나 여태? 고민된다.		[[DeleteMe]]) 이것이 되는 과정도 정확히 이해가 가지 않는다. 되는거였나 여태? 고민된다.

	maxObjects의 초기화 역시 문제로 대두 되는데, 다음과 같이 초기화 시킨다.		maxObjects의 초기화 역시 문제로 대두 되는데, 다음과 같이 초기화 시킨다.
Line 695:		Line 695:
	후자의 순서로 코드가 생성되어도 컴파일러에게 잘못은 전혀 없다. 그렇지만 '''set-a-bit-in-operator-new''' 방법을 사용한 상단의 예제는 두번째 순서에서는 실패 할수 밖에 없다.		후자의 순서로 코드가 생성되어도 컴파일러에게 잘못은 전혀 없다. 그렇지만 '''set-a-bit-in-operator-new''' 방법을 사용한 상단의 예제는 두번째 순서에서는 실패 할수 밖에 없다.

	* DeleteMe 주제 변환점		* [[DeleteMe]] 주제 변환점
	이런 어려움이 "각 생성자에서 *this가 heap영역에 있는가에 대한 여부를 알아낸다." 라는 아이디어의 근간을 흔드는 것은 아니다. 거기에다가 이런 어려움들은 operator new나 operator new[] 안에서 bit set을 점검해 보는 것이 이런 기본 정보를 결정하는데 신뢰성 있는 방법이 아님을 반증하고 있다. 우리가 필요한 방법을 위해서 한번 생각해 본다.		이런 어려움이 "각 생성자에서 *this가 heap영역에 있는가에 대한 여부를 알아낸다." 라는 아이디어의 근간을 흔드는 것은 아니다. 거기에다가 이런 어려움들은 operator new나 operator new[] 안에서 bit set을 점검해 보는 것이 이런 기본 정보를 결정하는데 신뢰성 있는 방법이 아님을 반증하고 있다. 우리가 필요한 방법을 위해서 한번 생각해 본다.

Line 734:		Line 734:
	여담이라면, 이러한 방법은 대다수의 시스템에서 사실이지만, 꼭 그렇다고는 볼수 없다. 그러니까 완전히 not portable한게 아닌 semi-portable이라고 표현을 해야 하나. 그래서 앞머리에 잠시나마 생각해 보자고 한것이고, 이러한 시스템 의존적인 설계는 차후 다른 시스템에 이식시에 메모리의 표현 방법이 다르다면, 소프트웨어 자체를 다시 설계해야 하는 위험성이 있다. 그냥 알고만 있자.		여담이라면, 이러한 방법은 대다수의 시스템에서 사실이지만, 꼭 그렇다고는 볼수 없다. 그러니까 완전히 not portable한게 아닌 semi-portable이라고 표현을 해야 하나. 그래서 앞머리에 잠시나마 생각해 보자고 한것이고, 이러한 시스템 의존적인 설계는 차후 다른 시스템에 이식시에 메모리의 표현 방법이 다르다면, 소프트웨어 자체를 다시 설계해야 하는 위험성이 있다. 그냥 알고만 있자.

	* DeleteMe 주제 변환점		* [[DeleteMe]] 주제 변환점
	우리는 앞쪽에서 "delete this"로 가상 파괴자로 객체가 스스로를 자살 시키는 방법으로 heap객체만을 사용하도록 제한 시키는 방법을 기억할 것이다. 이런 "delete this"식으로의 제거는 추천할 만한 방법이 결코 아니다. ( DeleteMe 모호) 그렇지만, 지우기 위한 객체의 안전성을 아는 것은 heap상에서 포인터가 지칭하는가를 간단히 알아네고자 하는 방법과 같은 것이 아니다. 자, 다시 UPNumber 객체를 가지는 Asset 객체의 관해서 생각해 보자.		우리는 앞쪽에서 "delete this"로 가상 파괴자로 객체가 스스로를 자살 시키는 방법으로 heap객체만을 사용하도록 제한 시키는 방법을 기억할 것이다. 이런 "delete this"식으로의 제거는 추천할 만한 방법이 결코 아니다. ( [[DeleteMe]] 모호) 그렇지만, 지우기 위한 객체의 안전성을 아는 것은 heap상에서 포인터가 지칭하는가를 간단히 알아네고자 하는 방법과 같은 것이 아니다. 자, 다시 UPNumber 객체를 가지는 Asset 객체의 관해서 생각해 보자.
	class Asset {		class Asset {
	private:		private:
Line 768:		Line 768:
	실제로 세가지 생각이 이러한 디자인을 매달리지 못하게 한다. '''첫번째는''' 전역 공간에 어떤것을 정의하는 극도로 피하려는 경향이다. operator enw나 operator delete같은 미리 정의된 함수에 대하여 특별하게 고친다는 것은 더 그럴 것이다. '''둘째로''' 효율에 관한 문제이다. 모든 메모리 할당에서 overhead가 발생한다는 의미인데, 이것을 유지하겠는가? '''마지막으로''' 걱정되는 것은 평범하지만 중요한 것으로 isSafeToDelete이 모든 수행에 관하여 적용되는 적용하는 것이다. 하지만 이것이 근본적으로 불가능하다고 보이기 때문이다. 조금더 이약 해보자면, 다중 상속이나, virtual base class가 가지는 여러게의 주소들, 이 주소들 때문에 isSafeTo Delete에게 전달되는 주소에 대한 확실한 보장이 없다. 자세한 내용은 Item 24, 31일 참고하라.		실제로 세가지 생각이 이러한 디자인을 매달리지 못하게 한다. '''첫번째는''' 전역 공간에 어떤것을 정의하는 극도로 피하려는 경향이다. operator enw나 operator delete같은 미리 정의된 함수에 대하여 특별하게 고친다는 것은 더 그럴 것이다. '''둘째로''' 효율에 관한 문제이다. 모든 메모리 할당에서 overhead가 발생한다는 의미인데, 이것을 유지하겠는가? '''마지막으로''' 걱정되는 것은 평범하지만 중요한 것으로 isSafeToDelete이 모든 수행에 관하여 적용되는 적용하는 것이다. 하지만 이것이 근본적으로 불가능하다고 보이기 때문이다. 조금더 이약 해보자면, 다중 상속이나, virtual base class가 가지는 여러게의 주소들, 이 주소들 때문에 isSafeTo Delete에게 전달되는 주소에 대한 확실한 보장이 없다. 자세한 내용은 Item 24, 31일 참고하라.

	* DeleteMe)주제 전환		* [[DeleteMe]])주제 전환
	자 위의 이유로 이번 아이디어도 쓰레기통으로 들어갈 참이다. 하지만 그 아이디어를 채용해서 C++에서는 abstract base class를 제공할수 있다. 여기서는 abstract mixin base class라고 표현한다.		자 위의 이유로 이번 아이디어도 쓰레기통으로 들어갈 참이다. 하지만 그 아이디어를 채용해서 C++에서는 abstract base class를 제공할수 있다. 여기서는 abstract mixin base class라고 표현한다.

Line 832:		Line 832:
	멤버 메소드 isOnHeap에 존재하는 이 구문이 다소 의문이 들것이다.		멤버 메소드 isOnHeap에 존재하는 이 구문이 다소 의문이 들것이다.
	const void rawAddress = dynamic_cast<const void>(this);		const void rawAddress = dynamic_cast<const void>(this);
	( DeleteMe 모호 )		( [[DeleteMe]] 모호 )
	위에서 isSafeToDelete를 구현할때 다중 상속이나 가상 기초 함수으로 여러개의 주소를 가지고 있는 객체가 전역의 해당 함수를 복잡하게 할것이라고 언급했다. 그런 문제는 isOnHeap에서 역시 마찬가지이다. 하지만 isOnHeap는 오직 HeapTracked객체에 적용 시킨 것이기 때문에, dynamic_cast operatror를 활용으로 위의 문제를 제거한다. 간단히 포인터를 dynamic_cast 하는 것은 (혹은 const void* or volatile void* or 알맞는 것으로 맞추어서) 객체의 가장 앞쪽 포인터, 즉, 할당된 메모리의 가장 앞쪽에 주소를 가리키는 포인터를 의미한다. 그렇지만 dynamic_cast는 가상함수를 하나 이상 가지는 객체를 가리키는 포인터에 한해서만 허용 된다. isSafeToDelete함수는 모든 포인터에 관해서 가능하기 때문에 dynamic_cast가 아무런 소용이 없다. isOnHeap는 조금더 선택의 폭이 있어서 this를 const void*로 dynamic_cast하는 것은 우리에게 현재 객체의 메모리 시작점의ㅣ 포인터를 주게 된다. 그 포인터는 HeapTracked::operator new가 반드시 반환해야만 하는 것으로 HeapTrack::operator new의 처음 부분에 있다. 당신의 컴파일러가 dynamix_cast를 지원하면 이러한 기술은 이식성이 높다.		위에서 isSafeToDelete를 구현할때 다중 상속이나 가상 기초 함수으로 여러개의 주소를 가지고 있는 객체가 전역의 해당 함수를 복잡하게 할것이라고 언급했다. 그런 문제는 isOnHeap에서 역시 마찬가지이다. 하지만 isOnHeap는 오직 HeapTracked객체에 적용 시킨 것이기 때문에, dynamic_cast operatror를 활용으로 위의 문제를 제거한다. 간단히 포인터를 dynamic_cast 하는 것은 (혹은 const void* or volatile void* or 알맞는 것으로 맞추어서) 객체의 가장 앞쪽 포인터, 즉, 할당된 메모리의 가장 앞쪽에 주소를 가리키는 포인터를 의미한다. 그렇지만 dynamic_cast는 가상함수를 하나 이상 가지는 객체를 가리키는 포인터에 한해서만 허용 된다. isSafeToDelete함수는 모든 포인터에 관해서 가능하기 때문에 dynamic_cast가 아무런 소용이 없다. isOnHeap는 조금더 선택의 폭이 있어서 this를 const void*로 dynamic_cast하는 것은 우리에게 현재 객체의 메모리 시작점의ㅣ 포인터를 주게 된다. 그 포인터는 HeapTracked::operator new가 반드시 반환해야만 하는 것으로 HeapTrack::operator new의 처음 부분에 있다. 당신의 컴파일러가 dynamix_cast를 지원하면 이러한 기술은 이식성이 높다.

Maintenance script: Repair batch-0002 pages from live compare

2026-03-27T00:16:09Z

Repair batch-0002 pages from live compare

← Older revision		Revision as of 00:16, 27 March 2026
Line 678:		Line 678:

	하지만 이 코드다 능사가 아닌것이, 다음과 같은 객체의 배열을 선언하면 문제가 된다.		하지만 이 코드다 능사가 아닌것이, 다음과 같은 객체의 배열을 선언하면 문제가 된다.
	UPNumber *numberArray = new UPNumber[100];		UPNumber *numberArray = new UPNumber[100];
	첫째로, 이 경우 operator new가 불리는 것이 아니라. 메모리는 operator new[]로 할당 되기때문에, 문제가 발생하는 것이고, 둘째로 operator new[]에 플래그 값을 주었다고 하더라도, 처음 한번의 operaotr new[]이후에 계속 생성자 100번이 불리면서 첫번째 생성자에서 다시 onTheHeap를 false로 초기화 시키기에, 이후에 불리는 생성자는 전부 onTheHeap이 false값으로 예외를 발생 시켜 버린다.		첫째로, 이 경우 operator new가 불리는 것이 아니라. 메모리는 operator new[]로 할당 되기때문에, 문제가 발생하는 것이고, 둘째로 operator new[]에 플래그 값을 주었다고 하더라도, 처음 한번의 operaotr new[]이후에 계속 생성자 100번이 불리면서 첫번째 생성자에서 다시 onTheHeap를 false로 초기화 시키기에, 이후에 불리는 생성자는 전부 onTheHeap이 false값으로 예외를 발생 시켜 버린다.

Maintenance script: Repair MoniWiki formatting after migration

2026-03-26T14:01:40Z

Repair MoniWiki formatting after migration

imported>Unknown at 05:23, 7 February 2021

2021-02-07T05:23:49Z

Show changes

← Older revision		Revision as of 14:01, 26 March 2026
Line 531:		Line 531:
	이해가 안가는 부분은 역시나 using이 쓰인 곳과 private로 상속 되었다는 점일 것이다.		이해가 안가는 부분은 역시나 using이 쓰인 곳과 private로 상속 되었다는 점일 것이다.

	private를 먼저 설명해 한다. 결론부터 이야기하면 위험성 제거와, 크기의 최적화를 위해서 이다. 다른 이가 Counted~~<~~Printer~~>~~ 포인터를 통해서 Printer객체를 제거하려는 시도를 할지도 모른다. 이를 방지하고, private상속은 Item 24에 명백히 나와 있듯이 Counted내의 가상 함수가 존재 하더라도, Printer에서 해당 가상 함수에 대한 vtbl을 생성하지 않으므로서 overhead를 줄인다.		private를 먼저 설명해 한다. 결론부터 이야기하면 위험성 제거와, 크기의 최적화를 위해서 이다. 다른 이가 Counted<Printer> 포인터를 통해서 Printer객체를 제거하려는 시도를 할지도 모른다. 이를 방지하고, private상속은 Item 24에 명백히 나와 있듯이 Counted내의 가상 함수가 존재 하더라도, Printer에서 해당 가상 함수에 대한 vtbl을 생성하지 않으므로서 overhead를 줄인다.

	using을 써서 Counted에 존재하는 인자를 참조 가능하게 만드는 이유는 Printer입장에서 다른 인자들은 신경 쓸필요가 없지만, 몇몇 특정한 인자의 참조와, 사용을 하기 위해서 이다. objectCount는 아래의 주석문의 이유이고,		using을 써서 Counted에 존재하는 인자를 참조 가능하게 만드는 이유는 Printer입장에서 다른 인자들은 신경 쓸필요가 없지만, 몇몇 특정한 인자의 참조와, 사용을 하기 위해서 이다. objectCount는 아래의 주석문의 이유이고,
Line 550:		Line 550:
	이는 using이 존재 하지 않았을때 사용된 옛날 문법이다. TooManyObjects 클래스 역시 같은 이유로 using을 이용해서 이름을 사용하게 권한을 열었으며, 이렇게 TooManyObjects를 허용해야 지만 해야지만 클라이언트들이 해당 예외를 잡을 수 있다.		이는 using이 존재 하지 않았을때 사용된 옛날 문법이다. TooManyObjects 클래스 역시 같은 이유로 using을 이용해서 이름을 사용하게 권한을 열었으며, 이렇게 TooManyObjects를 허용해야 지만 해야지만 클라이언트들이 해당 예외를 잡을 수 있다.

	생성자에서 감안할 것은 없다. 그냥 일반적인 생성과정을 기술해 주면 무리가 없으며, 필요한 작업은 Counted~~<~~Printer~~>~~의 생성자에서 하기때문에 Printer의 생성자는 다음고 같다.		생성자에서 감안할 것은 없다. 그냥 일반적인 생성과정을 기술해 주면 무리가 없으며, 필요한 작업은 Counted<Printer>의 생성자에서 하기때문에 Printer의 생성자는 다음고 같다.
	Printer::Printer()		Printer::Printer()
	{		{
	일반적인 생성자 과정		일반적인 생성자 과정
	}		}
	Printer의 생성자에서는 객체를 점검하는 코드가 들어가서는 안된다. 왜냐하면, Counted~~<~~Printer~~>~~에서 점검하고 이상 있어서 예외를 던진다면, 다음에 불릴 Printer생성자는 아예 불리지도 않는다. 알겠나?		Printer의 생성자에서는 객체를 점검하는 코드가 들어가서는 안된다. 왜냐하면, Counted<Printer>에서 점검하고 이상 있어서 예외를 던진다면, 다음에 불릴 Printer생성자는 아예 불리지도 않는다. 알겠나?

	또 하나는 object-counting시에 초기값이다. 이렇게 하면 초기화가 된다.		또 하나는 object-counting시에 초기값이다. 이렇게 하면 초기화가 된다.
Line 571:		Line 571:
	* Item 27: Heap영역을 사용하는 객체 요구하기 or 피하기.		* Item 27: Heap영역을 사용하는 객체 요구하기 or 피하기.

	이번 장에서는 Heap영역에서 객체 사용에 관하여 다루어 본다.		이번 장에서는 Heap영역에서 객체 사용에 관하여 다루어 본다. <br />
	때로 자살을 허용해야 하는 객체를 만들때도 있다. 표현이 격한가? "delete this"따위 같이 말이다. 이러한 객체는 heap영역에 배치 되는데, 확실하게 제거만 해준다면 자원이 셀 이유는 없다. 그렇다. 주의 깊게 다루어야 하는 객체들이다. embedded system같이 열악한 환경에서 이들에 잘못다루어서 일어난 실수는 치명적인 손상을 부른다. 이제 하나하나 heap영역에 관련한 내용을 다룬다.		때로 자살을 허용해야 하는 객체를 만들때도 있다. 표현이 격한가? "delete this"따위 같이 말이다. 이러한 객체는 heap영역에 배치 되는데, 확실하게 제거만 해준다면 자원이 셀 이유는 없다. 그렇다. 주의 깊게 다루어야 하는 객체들이다. embedded system같이 열악한 환경에서 이들에 잘못다루어서 일어난 실수는 치명적인 손상을 부른다. 이제 하나하나 heap영역에 관련한 내용을 다룬다.
	=== Requiring Heap-Based Objects : Heap 기반 객체들이 필요 ===		=== Requiring Heap-Based Objects : Heap 기반 객체들이 필요 ===
Line 1,069:		Line 1,069:
	...		...
	}		}
	printTreeNode에게 auto_ptr~~<~~TreeNode~~>~~ 형인 ptn이 값에 의한 전달(by-value)로 전달 되므로, printTreeNode가 수행되기전에 임시 객체가 생성되고 거기에 ptn이 복제 된다. 이때 불리는 복사 생성자(copy constructor)는 가지고 있는 더미(dumb) 포인터를 넘기는 소유권(ownership) 이양 작업을 하게되고, printerTreeNode가 마친뒤에 해당 객체는 삭제되고, ptn은 0(null)로 초기화 되어 진다. auto_ptr을 잃어 버린 것이다.		printTreeNode에게 auto_ptr<TreeNode> 형인 ptn이 값에 의한 전달(by-value)로 전달 되므로, printTreeNode가 수행되기전에 임시 객체가 생성되고 거기에 ptn이 복제 된다. 이때 불리는 복사 생성자(copy constructor)는 가지고 있는 더미(dumb) 포인터를 넘기는 소유권(ownership) 이양 작업을 하게되고, printerTreeNode가 마친뒤에 해당 객체는 삭제되고, ptn은 0(null)로 초기화 되어 진다. auto_ptr을 잃어 버린 것이다.

	그렇다면 값으로의 전달이 아닌 다른 방법이라면? 상수 참조 전달(Pass-by-reference-to-const)로 한다면 되지 않을까? 구현 코드를 보자		그렇다면 값으로의 전달이 아닌 다른 방법이라면? 상수 참조 전달(Pass-by-reference-to-const)로 한다면 되지 않을까? 구현 코드를 보자