MoreEffectiveC++/Techniques3of3 - Revision history

Maintenance script: Repair MoniWiki formatting after migration

2026-03-29T00:34:26Z

Repair MoniWiki formatting after migration

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 42:		Line 42:
	하나의 가능성은 C++의 사용을 줄이고, 다른 프로그래밍 언어를 선택하는 것이다. 예를들어, CLOS(Common Lisp Object System)로 전환 할수 있다. CLOS의 가장 일반적인 객체지향 함수 호출 기술의 하나(general object-oriented function-invocation mechanism one)로 해결이 가능하다.:가중 메소드(multi-method)기능. 다중 메소드(multi-method)는 당신이 원하는 여러개의 인자들로서 virtual(가상)을 구성할수 있고, CLOS는 당신의 조정으로 multi-method들의 오버로드(overload) 통한 방식으로 해결책을 준다.		하나의 가능성은 C++의 사용을 줄이고, 다른 프로그래밍 언어를 선택하는 것이다. 예를들어, CLOS(Common Lisp Object System)로 전환 할수 있다. CLOS의 가장 일반적인 객체지향 함수 호출 기술의 하나(general object-oriented function-invocation mechanism one)로 해결이 가능하다.:가중 메소드(multi-method)기능. 다중 메소드(multi-method)는 당신이 원하는 여러개의 인자들로서 virtual(가상)을 구성할수 있고, CLOS는 당신의 조정으로 multi-method들의 오버로드(overload) 통한 방식으로 해결책을 준다.

	dispatch [출발시키다]		dispatch [출발시키다]
	다중 프로그래밍 시스템에서 다음에 처리될 작업을 선택하여 실행시키는 것. 즉, 대기 열에서 기다리고		다중 프로그래밍 시스템에서 다음에 처리될 작업을 선택하여 실행시키는 것. 즉, 대기 열에서 기다리고
	있는 프로세스를 선택하여 중앙 처리 장치의 사용 권한을 부여하는 작업.		있는 프로세스를 선택하여 중앙 처리 장치의 사용 권한을 부여하는 작업.
Line 266:		Line 266:
	static HitMap collisionMap;		static HitMap collisionMap;

	collisionMap["SpaceShip"] = &hitSpaceShip;		collisionMap["SpaceShip"] = &hitSpaceShip;
	collisionMap["SpaceStation"] = &hitSpaceStation;		collisionMap["SpaceStation"] = &hitSpaceStation;
	collisionMap["Asteroid"] = &hitAsteroid;		collisionMap["Asteroid"] = &hitAsteroid;

	...		...
Line 308:		Line 308:
	HitMap *phm = new HitMap;		HitMap *phm = new HitMap;

	(*phm)["SpaceShip"] = &hitSpaceShip;		(*phm)["SpaceShip"] = &hitSpaceShip;
	(*phm)["SpaceStation"] = &hitSpaceStation;		(*phm)["SpaceStation"] = &hitSpaceStation;
	(*phm)["Asteroid"] = &hitAsteroid;		(*phm)["Asteroid"] = &hitAsteroid;

	return phm;		return phm;
Line 322:		Line 322:
	HitMap *phm = new HitMap;		HitMap *phm = new HitMap;

	(*phm)["SpaceShip"] = reinterpret_cast<HitFunctionPtr>(&hitSpaceShip);		(*phm)["SpaceShip"] = reinterpret_cast<HitFunctionPtr>(&hitSpaceShip);

	(*phm)["SpaceStation"] = reinterpret_cast<HitFunctionPtr>(&hitSpaceStation);		(*phm)["SpaceStation"] = reinterpret_cast<HitFunctionPtr>(&hitSpaceStation);

	(*phm)["Asteroid"] = reinterpret_cast<HitFunctionPtr>(&hitAsteroid);		(*phm)["Asteroid"] = reinterpret_cast<HitFunctionPtr>(&hitAsteroid);

	return phm;		return phm;
Line 366:		Line 366:
	HitMap *phm = new HitMap;		HitMap *phm = new HitMap;

	(*phm)["SpaceShip"] = &hitSpaceShip;		(*phm)["SpaceShip"] = &hitSpaceShip;
	(*phm)["SpaceStation"] = &hitSpaceStation;		(*phm)["SpaceStation"] = &hitSpaceStation;
	(*phm)["Asteroid"] = &hitAsteroid;		(*phm)["Asteroid"] = &hitAsteroid;

	return phm;		return phm;
Line 464:		Line 464:
	HitMap *phm = new HitMap;		HitMap *phm = new HitMap;

	(*phm)[makeStringPair("SpaceShip","Asteroid")] = &shipAsteroid;		(*phm)[makeStringPair("SpaceShip","Asteroid")] = &shipAsteroid;

	(*phm)[makeStringPair("SpaceShip", "SpaceStation")] = &shipStation;		(*phm)[makeStringPair("SpaceShip", "SpaceStation")] = &shipStation;
	...		...
	return phm;		return phm;
Line 585:		Line 585:
	&asteroidStation);		&asteroidStation);
	...		...
	int main(int argc, char * argv[])		int main(int argc, char * argv[])
	{		{
	...		...

Maintenance script: Repair MoniWiki formatting after migration

2026-03-26T14:01:40Z

Repair MoniWiki formatting after migration

← Older revision		Revision as of 14:01, 26 March 2026
Line 6:		Line 6:
	== Item 31: Making functions virtual with respect to more than one object. ==		== Item 31: Making functions virtual with respect to more than one object. ==
	* Item 31: 하나 이상 객체에 대응하는 함수를 virtual(가상)으로 동작 시키기		* Item 31: 하나 이상 객체에 대응하는 함수를 virtual(가상)으로 동작 시키기
	DeleteMe 모호		DeleteMe 모호 <br />
	Sometimes, to borrow a phrase from Jacquelin Sussan, once is not enugh. (의역:제클린 수잔에게서 말을 빌려 유식 한척하는데 한계가 있다. 정도. 이해안감)		Sometimes, to borrow a phrase from Jacquelin Sussan, once is not enugh. (의역:제클린 수잔에게서 말을 빌려 유식 한척하는데 한계가 있다. 정도. 이해안감)

Line 155:		Line 155:
	존재하는 클래스를 수정하는 것은 별로 좋지 못하다. 예를들어서, 당신이 스스로 전체의 비디오 게임 코드를 작성하는것 대신에, 비디오 게임 어플리 케이션 프레임 워크 내에서 off-the-shelf로서 코드를 조합해서 게임을 만들어 나간다고 한다면, 당신은 아마 GameObject클래스에 접근하는 코드나, 프레임 워크에서 유도되는 코드의 작성을 못할 것이다. 이러한 경우에, 새로운 맴버 함수나, 가상 혹은 다른 방법으로 생성할 방법이 없다. 대안으로, 당신은 수정을 요구하는, 클래스에 직접적인(physical) 접근을 해야 할것이다. 하지만 이러한 실질적인 (practical) 접근은 불가능하다. 예를들어서, 당신이 Nintendo에 고용되었고, 프로그램에서 사용하는 라이브러리에 GameObject와 다른 유용한 클래스들이 포함되어 있다고 가정하자. 확실히 당신은 GameObject의 단일 라이브러리의 사용만으로 프로그램을 만ㄷ르지 않을 것이다. 그래서 Nintendo는 아마 새로운 형의 객체가 프로그램에 추가될때마다 GameObject를 가진 라이브러리 만이 아닌, 전체를 재컴파일 해야 하는 더 심각한이 될것이다. 실질적으로 광범위하게 쓰이는 라이브러리를 수정하는 것은 흔하지 않다. 왜냐하면 모든걸 재 컴파일하는 비용이 너무 크기 때문이다.		존재하는 클래스를 수정하는 것은 별로 좋지 못하다. 예를들어서, 당신이 스스로 전체의 비디오 게임 코드를 작성하는것 대신에, 비디오 게임 어플리 케이션 프레임 워크 내에서 off-the-shelf로서 코드를 조합해서 게임을 만들어 나간다고 한다면, 당신은 아마 GameObject클래스에 접근하는 코드나, 프레임 워크에서 유도되는 코드의 작성을 못할 것이다. 이러한 경우에, 새로운 맴버 함수나, 가상 혹은 다른 방법으로 생성할 방법이 없다. 대안으로, 당신은 수정을 요구하는, 클래스에 직접적인(physical) 접근을 해야 할것이다. 하지만 이러한 실질적인 (practical) 접근은 불가능하다. 예를들어서, 당신이 Nintendo에 고용되었고, 프로그램에서 사용하는 라이브러리에 GameObject와 다른 유용한 클래스들이 포함되어 있다고 가정하자. 확실히 당신은 GameObject의 단일 라이브러리의 사용만으로 프로그램을 만ㄷ르지 않을 것이다. 그래서 Nintendo는 아마 새로운 형의 객체가 프로그램에 추가될때마다 GameObject를 가진 라이브러리 만이 아닌, 전체를 재컴파일 해야 하는 더 심각한이 될것이다. 실질적으로 광범위하게 쓰이는 라이브러리를 수정하는 것은 흔하지 않다. 왜냐하면 모든걸 재 컴파일하는 비용이 너무 크기 때문이다.

	DeleteMe 모호		DeleteMe 모호 <br />
	길든, 짧든 간에, 만약 당신이 double-dispatch을 구현할때, 최고의 자원이라 할수 있는것은, 디자인 상에서 필요 없는 인자를 제거 할수 있도록 수정이 가능한 것이다. 그것을 제한다면, 그렇지 않았을때 보다. 가상 함수가 RTTI의 전략에 보다 좀더 안전하게 접근하는 방법일 것이다. 그렇지만 이 경우 당신의 시스템에 확장성을 고려한다면, 해더 파일들을 조작해야 할것이다. RTTI로의 접근은, 아무런 재 컴파일에 하지 않는 반면에, 위와 같은 구현은 소프트웨어의 유지 보수에 악영향을 미친다.당신은 아마 당신의 비용을 지불하고, 당신의 기회 조차 지불하게 된다.		길든, 짧든 간에, 만약 당신이 double-dispatch을 구현할때, 최고의 자원이라 할수 있는것은, 디자인 상에서 필요 없는 인자를 제거 할수 있도록 수정이 가능한 것이다. 그것을 제한다면, 그렇지 않았을때 보다. 가상 함수가 RTTI의 전략에 보다 좀더 안전하게 접근하는 방법일 것이다. 그렇지만 이 경우 당신의 시스템에 확장성을 고려한다면, 해더 파일들을 조작해야 할것이다. RTTI로의 접근은, 아무런 재 컴파일에 하지 않는 반면에, 위와 같은 구현은 소프트웨어의 유지 보수에 악영향을 미친다.당신은 아마 당신의 비용을 지불하고, 당신의 기회 조차 지불하게 된다.

Line 607:		Line 607:
	----		----
	[[MoreEffectiveC++]]		[[MoreEffectiveC++]]

imported>Unknown at 05:23, 7 February 2021

2021-02-07T05:23:49Z

Show changes

← Older revision		Revision as of 00:34, 29 March 2026
Line 6:		Line 6:
	== Item 31: Making functions virtual with respect to more than one object. ==		== Item 31: Making functions virtual with respect to more than one object. ==
	* Item 31: 하나 이상 객체에 대응하는 함수를 virtual(가상)으로 동작 시키기		* Item 31: 하나 이상 객체에 대응하는 함수를 virtual(가상)으로 동작 시키기
	DeleteMe 모호 <br />		[[DeleteMe]] 모호 <br />
	Sometimes, to borrow a phrase from Jacquelin Sussan, once is not enugh. (의역:제클린 수잔에게서 말을 빌려 유식 한척하는데 한계가 있다. 정도. 이해안감)		Sometimes, to borrow a phrase from Jacquelin Sussan, once is not enugh. (의역:제클린 수잔에게서 말을 빌려 유식 한척하는데 한계가 있다. 정도. 이해안감)

Line 48:		Line 48:

	그렇지만 C++안에서만 당신의 게임을 구현해야 한다고 하자-이제 당신은 보통 double-dispatch 으로 불리는 기술에 대해 구현하는 방법을 찾아야 한다. (이 이름은 객체지향 프로그래밍 커뮤니티(object-oriented programming community)에서 C++의 가상함수를 "message dispatch"으로 부르는 C++프로그래머들에 의해서 불린다. 이 호출은 두개의 인자가 가상으로 동작하기위해 "double-dispatch"를 통하여 구현된다. 이것을 일반화 시키면,-함수는 가상으로 몇개의 인자를 가진다.- multi-dispatch 라고 부를수 있다.) 이번 아이템에서는 이를 구현하는데, 몇가지의 접근법을 다룰 것이다. 약점이 없는것이 없고, 그리 당신을 놀래킬 방법들도 아니다. C++는 double-dispat에 관한 직접적 지원을 안해서 반드시 가상함수 정도의 지원을 컴파일러가 해주어야 한다.(Item 24참고) 만약 컴파일러가 지원하면, 아마 우린 C에서 처럼 간단히 프로그래밍을 할것이고, 아니라면 각오해야 한다.		그렇지만 C++안에서만 당신의 게임을 구현해야 한다고 하자-이제 당신은 보통 double-dispatch 으로 불리는 기술에 대해 구현하는 방법을 찾아야 한다. (이 이름은 객체지향 프로그래밍 커뮤니티(object-oriented programming community)에서 C++의 가상함수를 "message dispatch"으로 부르는 C++프로그래머들에 의해서 불린다. 이 호출은 두개의 인자가 가상으로 동작하기위해 "double-dispatch"를 통하여 구현된다. 이것을 일반화 시키면,-함수는 가상으로 몇개의 인자를 가진다.- multi-dispatch 라고 부를수 있다.) 이번 아이템에서는 이를 구현하는데, 몇가지의 접근법을 다룰 것이다. 약점이 없는것이 없고, 그리 당신을 놀래킬 방법들도 아니다. C++는 double-dispat에 관한 직접적 지원을 안해서 반드시 가상함수 정도의 지원을 컴파일러가 해주어야 한다.(Item 24참고) 만약 컴파일러가 지원하면, 아마 우린 C에서 처럼 간단히 프로그래밍을 할것이고, 아니라면 각오해야 한다.
	=== Using Virtual Function and RTTI : 가상 함수와 RTTI사용 ===		=== Using Virtual Function and [[RTTI]] : 가상 함수와 RTTI사용 ===
	가상 함수는 single-dispatch로 구현된다. 이것은 우리가 구현하는 것에 반쪽에 불과하다. 그리고 컴파일러는, 이런 가상함수를 지원할수 있다. 그래서 가상함수인 collid를 GameObject내에 선언하는 것으로 시작해 보자. 이 함수는 유도되는 클래스에 의하여 오버라이드(overridden)된다.		가상 함수는 single-dispatch로 구현된다. 이것은 우리가 구현하는 것에 반쪽에 불과하다. 그리고 컴파일러는, 이런 가상함수를 지원할수 있다. 그래서 가상함수인 collid를 GameObject내에 선언하는 것으로 시작해 보자. 이 함수는 유도되는 클래스에 의하여 오버라이드(overridden)된다.
	class GameObject {		class GameObject {
Line 102:		Line 102:
	형기반의 프로그래밍이라면 C부터 있었던 오래된 개념이다. 그리고 우리가 알게 된것들중 하나는 근본적으로 유지 보수 하기에 너무 어렵다는 문제를 야기한다. 그런 프로그램이 점차 발전한다는 것은 아마 생각하기 힘들것이다. 이는 가상 함수가 등장하게된 첫번째 이유이다.:이유-형 기반의 함수를 유지 보수 하고 만드는 짐을 프로그래머에서 컴파일러로 넘긴다. RTTI가 double-dispatch 구현에 채용되면, 이러한 오래된 고민들을 다시 하는것이다.		형기반의 프로그래밍이라면 C부터 있었던 오래된 개념이다. 그리고 우리가 알게 된것들중 하나는 근본적으로 유지 보수 하기에 너무 어렵다는 문제를 야기한다. 그런 프로그램이 점차 발전한다는 것은 아마 생각하기 힘들것이다. 이는 가상 함수가 등장하게된 첫번째 이유이다.:이유-형 기반의 함수를 유지 보수 하고 만드는 짐을 프로그래머에서 컴파일러로 넘긴다. RTTI가 double-dispatch 구현에 채용되면, 이러한 오래된 고민들을 다시 하는것이다.

	C에너 논의된 에러의 가능성을 가진 이런 유산들은 C++에서도 역시 에러로 이끈다. 실수하기 쉬운 경우는, collide함수의 마지막 else 부분이다. 이 잘못은 만약 알수없는 객체의 경우 프로그램의 제어를 날려버린다. 이런 경우에는 원칙적으로 불가능 하지만, 우리가 RTTI 사용을 생각할때, 어디에 핵심이 있는가? 거기에는 다양한 방법의 많은 상호 작용이 있을수 있다. 아무도 완전히 만족 시킬수 없다. 이러한 경우에, 예외를 던지도록 선택한다. 그렇지만 함수의 호출자들은 이 에러를 확실히 잡아 해결할 방법 역시 명백하지 못하다.		C에너 논의된 에러의 가능성을 가진 이런 유산들은 C++에서도 역시 에러로 이끈다. 실수하기 쉬운 경우는, collide함수의 마지막 else 부분이다. 이 잘못은 만약 알수없는 객체의 경우 프로그램의 제어를 날려버린다. 이런 경우에는 원칙적으로 불가능 하지만, 우리가 [[RTTI]] 사용을 생각할때, 어디에 핵심이 있는가? 거기에는 다양한 방법의 많은 상호 작용이 있을수 있다. 아무도 완전히 만족 시킬수 없다. 이러한 경우에, 예외를 던지도록 선택한다. 그렇지만 함수의 호출자들은 이 에러를 확실히 잡아 해결할 방법 역시 명백하지 못하다.

	=== Using Virtual Functions Only : 가상 함수만 사용 ===		=== Using Virtual Functions Only : 가상 함수만 사용 ===
Line 155:		Line 155:
	존재하는 클래스를 수정하는 것은 별로 좋지 못하다. 예를들어서, 당신이 스스로 전체의 비디오 게임 코드를 작성하는것 대신에, 비디오 게임 어플리 케이션 프레임 워크 내에서 off-the-shelf로서 코드를 조합해서 게임을 만들어 나간다고 한다면, 당신은 아마 GameObject클래스에 접근하는 코드나, 프레임 워크에서 유도되는 코드의 작성을 못할 것이다. 이러한 경우에, 새로운 맴버 함수나, 가상 혹은 다른 방법으로 생성할 방법이 없다. 대안으로, 당신은 수정을 요구하는, 클래스에 직접적인(physical) 접근을 해야 할것이다. 하지만 이러한 실질적인 (practical) 접근은 불가능하다. 예를들어서, 당신이 Nintendo에 고용되었고, 프로그램에서 사용하는 라이브러리에 GameObject와 다른 유용한 클래스들이 포함되어 있다고 가정하자. 확실히 당신은 GameObject의 단일 라이브러리의 사용만으로 프로그램을 만ㄷ르지 않을 것이다. 그래서 Nintendo는 아마 새로운 형의 객체가 프로그램에 추가될때마다 GameObject를 가진 라이브러리 만이 아닌, 전체를 재컴파일 해야 하는 더 심각한이 될것이다. 실질적으로 광범위하게 쓰이는 라이브러리를 수정하는 것은 흔하지 않다. 왜냐하면 모든걸 재 컴파일하는 비용이 너무 크기 때문이다.		존재하는 클래스를 수정하는 것은 별로 좋지 못하다. 예를들어서, 당신이 스스로 전체의 비디오 게임 코드를 작성하는것 대신에, 비디오 게임 어플리 케이션 프레임 워크 내에서 off-the-shelf로서 코드를 조합해서 게임을 만들어 나간다고 한다면, 당신은 아마 GameObject클래스에 접근하는 코드나, 프레임 워크에서 유도되는 코드의 작성을 못할 것이다. 이러한 경우에, 새로운 맴버 함수나, 가상 혹은 다른 방법으로 생성할 방법이 없다. 대안으로, 당신은 수정을 요구하는, 클래스에 직접적인(physical) 접근을 해야 할것이다. 하지만 이러한 실질적인 (practical) 접근은 불가능하다. 예를들어서, 당신이 Nintendo에 고용되었고, 프로그램에서 사용하는 라이브러리에 GameObject와 다른 유용한 클래스들이 포함되어 있다고 가정하자. 확실히 당신은 GameObject의 단일 라이브러리의 사용만으로 프로그램을 만ㄷ르지 않을 것이다. 그래서 Nintendo는 아마 새로운 형의 객체가 프로그램에 추가될때마다 GameObject를 가진 라이브러리 만이 아닌, 전체를 재컴파일 해야 하는 더 심각한이 될것이다. 실질적으로 광범위하게 쓰이는 라이브러리를 수정하는 것은 흔하지 않다. 왜냐하면 모든걸 재 컴파일하는 비용이 너무 크기 때문이다.

	DeleteMe 모호 <br />		[[DeleteMe]] 모호 <br />
	길든, 짧든 간에, 만약 당신이 double-dispatch을 구현할때, 최고의 자원이라 할수 있는것은, 디자인 상에서 필요 없는 인자를 제거 할수 있도록 수정이 가능한 것이다. 그것을 제한다면, 그렇지 않았을때 보다. 가상 함수가 RTTI의 전략에 보다 좀더 안전하게 접근하는 방법일 것이다. 그렇지만 이 경우 당신의 시스템에 확장성을 고려한다면, 해더 파일들을 조작해야 할것이다. RTTI로의 접근은, 아무런 재 컴파일에 하지 않는 반면에, 위와 같은 구현은 소프트웨어의 유지 보수에 악영향을 미친다.당신은 아마 당신의 비용을 지불하고, 당신의 기회 조차 지불하게 된다.		길든, 짧든 간에, 만약 당신이 double-dispatch을 구현할때, 최고의 자원이라 할수 있는것은, 디자인 상에서 필요 없는 인자를 제거 할수 있도록 수정이 가능한 것이다. 그것을 제한다면, 그렇지 않았을때 보다. 가상 함수가 RTTI의 전략에 보다 좀더 안전하게 접근하는 방법일 것이다. 그렇지만 이 경우 당신의 시스템에 확장성을 고려한다면, 해더 파일들을 조작해야 할것이다. RTTI로의 접근은, 아무런 재 컴파일에 하지 않는 반면에, 위와 같은 구현은 소프트웨어의 유지 보수에 악영향을 미친다.당신은 아마 당신의 비용을 지불하고, 당신의 기회 조차 지불하게 된다.

Line 161:		Line 161:
	좀더 좋은 기회 가지는 방법이 있다. Item 24에서 컴파일러가 보통 가상함수를 함수 포인터(vtbl) 배열로 생성하고, 그후 가상함수가 불릴때 인덱스로 함수 호출을 구현하는 것을 기억하라. vtbl의 사용은 컴파일러가 if-then-else 같은 연산의 체인을 제거하는대 필요하고, 컴파일러가 모든 가상 함수에 대하여 비슷한 코드의 생성을 하도록 만든다.:정확한 vtbl 인텍스 결정, 그리고 함수의 호출은 vtbl의 위치에 달려있다.		좀더 좋은 기회 가지는 방법이 있다. Item 24에서 컴파일러가 보통 가상함수를 함수 포인터(vtbl) 배열로 생성하고, 그후 가상함수가 불릴때 인덱스로 함수 호출을 구현하는 것을 기억하라. vtbl의 사용은 컴파일러가 if-then-else 같은 연산의 체인을 제거하는대 필요하고, 컴파일러가 모든 가상 함수에 대하여 비슷한 코드의 생성을 하도록 만든다.:정확한 vtbl 인텍스 결정, 그리고 함수의 호출은 vtbl의 위치에 달려있다.

	당신도 이런걸 할수 없다는 근거는 없다. 이걸 구현한다면, RTTI만을 쓴거보다는 더 효율적으로 만들수 없다. (배열의 인덱싱과 함수 포인터를 허용하는것은 거의 if-then-else보다 더 효율적이다. 그리고 생성되는 코드 역시 마찬가지이다.), 또한 한곳에 RTTI 사용을 하는 것으로 제한한다.:함수 포인터가 초기화되는 곳.		당신도 이런걸 할수 없다는 근거는 없다. 이걸 구현한다면, RTTI만을 쓴거보다는 더 효율적으로 만들수 없다. (배열의 인덱싱과 함수 포인터를 허용하는것은 거의 if-then-else보다 더 효율적이다. 그리고 생성되는 코드 역시 마찬가지이다.), 또한 한곳에 [[RTTI]] 사용을 하는 것으로 제한한다.:함수 포인터가 초기화되는 곳.

	DeleteMe 해석 보류 (I should mention that the meek may inherit the earth, but meek of heart may wish to take a few deep breaths before reading what follows.:구지 해석하면, 다른 사람을 쫓는 줏대없는 짓이라고 할지 모른다. 그렇지만, 다음 내용을 보기전까지는 뾰족한 수가 없을꺼다.) (작성자주:난 한국인이야!! - 자기 합리화)		[[DeleteMe]] 해석 보류 (I should mention that the meek may inherit the earth, but meek of heart may wish to take a few deep breaths before reading what follows.:구지 해석하면, 다른 사람을 쫓는 줏대없는 짓이라고 할지 모른다. 그렇지만, 다음 내용을 보기전까지는 뾰족한 수가 없을꺼다.) (작성자주:난 한국인이야!! - 자기 합리화)

	자자, 몇가지 GameObject의 상속관계에서 함수들을 수정해서 시작한다.		자자, 몇가지 GameObject의 상속관계에서 함수들을 수정해서 시작한다.
Line 191:		Line 191:
	SpaceShip-Asteroid 간의 충돌 수행;		SpaceShip-Asteroid 간의 충돌 수행;
	}		}
	RTTI 기반의 계층과 비슷한 모습으로 시작하는데, 우리는 GameObject 클래스가 충돌 과정에 대한 함수를 하나씩 가지고, 필요한 두가지의 dispatch의 수행을 하나에서 한다. 나중에 볼 가상함수 기반의 상속 관계와 비슷하게, 이건 경우의 함수는 collide로 이름을 공유하는 대신에 다른 이름을 사용하지만, 각 반응은 분리된 함수로서 캡슐화 된다. 이럴 경우, 오버로딩의 부재가 생각된다. 아마 곧 보여질 거다. 위의 디자인은 SpaceShip::collide를 위한 구현을 제외한 필요한 모든것을 포함하고 있다는 걸 살피자.;다양한 hit함수가 불린다. 그 전에, 일단 SpaceShip 클래스를 성공적으로 구현하고, SpaceStation과 Asteroid클래스도 적절히 구현해야 한다.		[[RTTI]] 기반의 계층과 비슷한 모습으로 시작하는데, 우리는 GameObject 클래스가 충돌 과정에 대한 함수를 하나씩 가지고, 필요한 두가지의 dispatch의 수행을 하나에서 한다. 나중에 볼 가상함수 기반의 상속 관계와 비슷하게, 이건 경우의 함수는 collide로 이름을 공유하는 대신에 다른 이름을 사용하지만, 각 반응은 분리된 함수로서 캡슐화 된다. 이럴 경우, 오버로딩의 부재가 생각된다. 아마 곧 보여질 거다. 위의 디자인은 SpaceShip::collide를 위한 구현을 제외한 필요한 모든것을 포함하고 있다는 걸 살피자.;다양한 hit함수가 불린다. 그 전에, 일단 SpaceShip 클래스를 성공적으로 구현하고, SpaceStation과 Asteroid클래스도 적절히 구현해야 한다.

	SpaceShip::collide 내부에 우리는 동적 형태의 인자인 otherObject를 그 형에 적합한 충돌체크를 하는 멤버 함수에 연결시켜야 하는 방법이 필요하다. 가장 쉬운 방법은 클래스 이름을 주어서 관련배열(associative array:이하 관련배열)을 생성하는 것으로, 함수 포인터 멤버에 올바르게 유도한다. collide에 이러한 관련배열(associative array)을 적용시켜 구현할수 있지만, 이해하기에 조금 더 쉬운 방법은 중재하는 함수인 lookup 함수를 GameObject에 추가하는 것이다. lookup은 적합한 멤버 함수 포인터를 반환한다. 그렇게 GameObject를 lookup에 넘기는 것과 반환되는 멤버 함수 포인터는 GameObject의 형에 충돌을 수행한다.		SpaceShip::collide 내부에 우리는 동적 형태의 인자인 otherObject를 그 형에 적합한 충돌체크를 하는 멤버 함수에 연결시켜야 하는 방법이 필요하다. 가장 쉬운 방법은 클래스 이름을 주어서 관련배열(associative array:이하 관련배열)을 생성하는 것으로, 함수 포인터 멤버에 올바르게 유도한다. collide에 이러한 관련배열(associative array)을 적용시켜 구현할수 있지만, 이해하기에 조금 더 쉬운 방법은 중재하는 함수인 lookup 함수를 GameObject에 추가하는 것이다. lookup은 적합한 멤버 함수 포인터를 반환한다. 그렇게 GameObject를 lookup에 넘기는 것과 반환되는 멤버 함수 포인터는 GameObject의 형에 충돌을 수행한다.
Line 512:		Line 512: