MoreEffectiveC++/Miscellany - 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 465:		Line 465:
	main이 수행되기 전에 객체가 생성되야 하는 필요성이 있지만, main이 가장 처음 불려야 하는것으로 가정되는 딜레마의 해결을 위해서, 많은 컴파일러 들이 특별한 컴파일러가 작성하는 함수를 main의 시작단에 넣는다. 그리고 이 특별한 한수는 static initialization 을 한다. 비슷하게 컴파얼러는 종종 main의 끝에 특별한 함수를 넣어서 static 객체의 삭제를 수행한다. main 에 대해 작성되는 코드는 종종 main 이 엃게 작성되는 것처럼 보인다.		main이 수행되기 전에 객체가 생성되야 하는 필요성이 있지만, main이 가장 처음 불려야 하는것으로 가정되는 딜레마의 해결을 위해서, 많은 컴파일러 들이 특별한 컴파일러가 작성하는 함수를 main의 시작단에 넣는다. 그리고 이 특별한 한수는 static initialization 을 한다. 비슷하게 컴파얼러는 종종 main의 끝에 특별한 함수를 넣어서 static 객체의 삭제를 수행한다. main 에 대해 작성되는 코드는 종종 main 이 엃게 작성되는 것처럼 보인다.

	int main(int argc, char *argv[])		int main(int argc, char *argv[])
	{		{
	performStaticInitialization(); // main이 넣는다고 가정하는 함수		performStaticInitialization(); // main이 넣는다고 가정하는 함수
Line 478:		Line 478:
	때때로 C에 main 작성이 더 가치 있다고 보인다. - 대다수 프로그램이 C이고, C++이 단지 라이브러리 지원 이라면 이라고 말해라. 그렇기는 하지만, C++ 라이브러리는 정적(static) 객체(object)를 포함하는 것이 좋다.(좋은 기능이 많다는 의미) (만약 지금 없다해도 미래에 어쩌면 있을지 모르지 않는가? Item 32참고) 그래서 가능하다면 C++에서 main을 작성은 좋은 생각이다. 그것은 당신의 C코드를 제작성 하는것을 의미하지는 않는다. 단지 C에서 쓴 main을 realMain으로 이름만 바꾸고, main의 C++버전에서는 realMain을 호출한다.:		때때로 C에 main 작성이 더 가치 있다고 보인다. - 대다수 프로그램이 C이고, C++이 단지 라이브러리 지원 이라면 이라고 말해라. 그렇기는 하지만, C++ 라이브러리는 정적(static) 객체(object)를 포함하는 것이 좋다.(좋은 기능이 많다는 의미) (만약 지금 없다해도 미래에 어쩌면 있을지 모르지 않는가? Item 32참고) 그래서 가능하다면 C++에서 main을 작성은 좋은 생각이다. 그것은 당신의 C코드를 제작성 하는것을 의미하지는 않는다. 단지 C에서 쓴 main을 realMain으로 이름만 바꾸고, main의 C++버전에서는 realMain을 호출한다.:
	extern "C"		extern "C"
	int realMain(int argc, char *argv[]); // C 에서 구현된 함수		int realMain(int argc, char *argv[]); // C 에서 구현된 함수

	int main(int argc, char *argv[]) // C++에서 이렇게 작성		int main(int argc, char *argv[]) // C++에서 이렇게 작성
	{		{
	return realMain(argc, argv);		return realMain(argc, argv);
Line 582:		Line 582:
	당신은 찾기 함수(find function)를 다음과 같이 사용할수 있다.		당신은 찾기 함수(find function)를 다음과 같이 사용할수 있다.

	int values[50];		int values[50];
	...		...

	int *firstFive = find( values, // 숫자 5를		int *firstFive = find( values, // 숫자 5를
	values+50, // value[0] - value[49]		values+50, // value[0] - value[49]
	5); // 까지 검색		5); // 까지 검색

Line 598:		Line 598:
	당신은 배열의 subrange 검색도 할수 있다.		당신은 배열의 subrange 검색도 할수 있다.
	int *firstFive = find(values, // search the range		int *firstFive = find(values, // search the range
	values+10, // values[0] - values[9]		values+10, // values[0] - values[9]
	5); // for the value 5		5); // for the value 5

Line 606:		Line 606:

	int *firstValue = find(values+10, // search the range		int *firstValue = find(values+10, // search the range
	values+20, // values[10] - values[19]		values+20, // values[10] - values[19]
	age); // for the value in age		age); // for the value in age

Line 653:		Line 653:

	다른 STL continer들을 이용해서 정확히 같은 접근을 해본다. 게다가 C++ 포인터는 STL iterator이다. 그래서 원래 배열 예제는 STL find 함수도 역시 이용할수 있다.		다른 STL continer들을 이용해서 정확히 같은 접근을 해본다. 게다가 C++ 포인터는 STL iterator이다. 그래서 원래 배열 예제는 STL find 함수도 역시 이용할수 있다.
	int values[50];		int values[50];

	...		...

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 21:		Line 21:


	DeleteMe 모호		DeleteMe 모호 <br />
	"변화한다.", 험난한 소프트웨어의 발전에 잘 견디는 클래스를 작성하라. (원문:Given that things will change, writeclasses that can withstand the rough-and-tumble world of software evolution.) "demand-paged"의 가상 함수를 피하라. 다른 이가 만들어 놓지 않으면, 너도 만들 방법이 없는 그런 경우를 피하라.(모호, 원문:Avoid "demand-paged" virtual functions, whereby you make no functions virtual unless somebody comes along and demands that you do it) 대신에 함수의 ''meaning''을 결정하고, 유도된 클래스에서 새롭게 정의할 것인지 판단하라. 그렇게 되면, 가상(virtual)으로 선언해라, 어떤 이라도 재정의 못할지라도 말이다. 그렇지 않다면, 비가상(nonvirtual)으로 선언해라, 그리고 차후에 그것을 바꾸어라 왜냐하면 그것은 다른사람을 편하게 하기 때문이다.;전체 클래스의 목적에서 변화를 유지하는지 확신을 해라.		"변화한다.", 험난한 소프트웨어의 발전에 잘 견디는 클래스를 작성하라. (원문:Given that things will change, writeclasses that can withstand the rough-and-tumble world of software evolution.) "demand-paged"의 가상 함수를 피하라. 다른 이가 만들어 놓지 않으면, 너도 만들 방법이 없는 그런 경우를 피하라.(모호, 원문:Avoid "demand-paged" virtual functions, whereby you make no functions virtual unless somebody comes along and demands that you do it) 대신에 함수의 ''meaning''을 결정하고, 유도된 클래스에서 새롭게 정의할 것인지 판단하라. 그렇게 되면, 가상(virtual)으로 선언해라, 어떤 이라도 재정의 못할지라도 말이다. 그렇지 않다면, 비가상(nonvirtual)으로 선언해라, 그리고 차후에 그것을 바꾸어라 왜냐하면 그것은 다른사람을 편하게 하기 때문이다.;전체 클래스의 목적에서 변화를 유지하는지 확신을 해라.

Line 544:		Line 544:
	'''첫번째''' 라이브러리 안의 거의 모든것이 template이다. 이 책 내에서 나는 아마도 표준 string 클래스를 참고 했다. 그러나 사실 그런 클래스가 아니다. 대신에 문자들의 순서를 표현하는 basic_string 으로 불리는 클래스 템플릿이고, 이 템플릿은 문자형으로 순서를 만든다. 이것은 문자열을 char, wide char, Unide char, 무엇이든 허용한다.		'''첫번째''' 라이브러리 안의 거의 모든것이 template이다. 이 책 내에서 나는 아마도 표준 string 클래스를 참고 했다. 그러나 사실 그런 클래스가 아니다. 대신에 문자들의 순서를 표현하는 basic_string 으로 불리는 클래스 템플릿이고, 이 템플릿은 문자형으로 순서를 만든다. 이것은 문자열을 char, wide char, Unide char, 무엇이든 허용한다.

	우리가 일반적으로 생각하는 string 클래스는 basic_string~~<~~char~~>~~을 명시적으로 표현한 것이다. 이것을 일반화 시키기 위하여 표준 라이브러리에서는 다음과 같이 정의하고 있다.		우리가 일반적으로 생각하는 string 클래스는 basic_string<char>을 명시적으로 표현한 것이다. 이것을 일반화 시키기 위하여 표준 라이브러리에서는 다음과 같이 정의하고 있다.
	typedef basic_string<char> string;		typedef basic_string<char> string;
	basic_string 템플릿이 세가지의 논의를 가지고 아서, 이 한줄에 조차 자세하게 주석을 달수 있다.;그렇지만 무엇보다 먼저 생각할것 '''첫번째'''는 기본 값이다. ''진짜'' string 형의 이해를 위해서 반드시 이와 같은 상황에 직면하는데, 바로 basic_string에 대한 선언을 수정할수 없는가? 이다.		basic_string 템플릿이 세가지의 논의를 가지고 아서, 이 한줄에 조차 자세하게 주석을 달수 있다.;그렇지만 무엇보다 먼저 생각할것 '''첫번째'''는 기본 값이다. ''진짜'' string 형의 이해를 위해서 반드시 이와 같은 상황에 직면하는데, 바로 basic_string에 대한 선언을 수정할수 없는가? 이다.
Line 650:		Line 650:
	list 객체를 찾기 위한 호출을 위해서, 당신은 list의 가장 처음 인자와 list와 가장 마지막의 인자를 가리키는 iterator가 필요하다. 리크트 클래스에 의한 몇가지의 도움 될 기능들을 제외하고, 이것은 어려운 문제이다. 왜냐하면 당신은 list가 어떻게 구현되었는 가에 관한 정보가 없기 때문이다. 다행 스럽게다 리스크(list,모든 STL의 container들과 같이) 시작과 끝을 제공하는 멤버 함수로서 해결한다. 이 멤버 함수는 당신이 원하는 iterator 반환하고 위의 예제에서 해당 iterator 두가지를 찾을수 있다.		list 객체를 찾기 위한 호출을 위해서, 당신은 list의 가장 처음 인자와 list와 가장 마지막의 인자를 가리키는 iterator가 필요하다. 리크트 클래스에 의한 몇가지의 도움 될 기능들을 제외하고, 이것은 어려운 문제이다. 왜냐하면 당신은 list가 어떻게 구현되었는 가에 관한 정보가 없기 때문이다. 다행 스럽게다 리스크(list,모든 STL의 container들과 같이) 시작과 끝을 제공하는 멤버 함수로서 해결한다. 이 멤버 함수는 당신이 원하는 iterator 반환하고 위의 예제에서 해당 iterator 두가지를 찾을수 있다.

	찾기(find)가 끝났으면 그것은 찾은 인자를 가리키는, 혹은 charList.end()(찾지 못하였을때)의 iterator 객체를 반환한다. 왜냐하면 당신은 list가 어떻게 구현되었는가에 대하여 아무것도 알수 없기때문에 역시 구현된 list에서 iterator가 어떻게 되었는지 전혀 알수 없다. 그런데 어떻게 찾고서 반환되어지는 객체의 형을 알수 있을까? 다시, list 클래스는 모든 STL container와 마찬가지로 제한 해제를 한다.: 그것은 형 정의, iterator, 즉 list내부의 iterator의 정의를 제공한다. charList 가 char의 list가 된 이후로 iterator의 정의는 그러한 list인 list~~<~~char~~>~~::iterator 내부에 있고, 그것은 위의 예제와 같이 쓰인다. (각 STL container 클래스는 두가지의 iteraotr형인 '''iterator''' 와 '''const_iteraotr''' 를 정의한다. 전자는 일반적인 pointer와 같이 동작하고 후자는 pointer-to-const와 같이 동작한다. )		찾기(find)가 끝났으면 그것은 찾은 인자를 가리키는, 혹은 charList.end()(찾지 못하였을때)의 iterator 객체를 반환한다. 왜냐하면 당신은 list가 어떻게 구현되었는가에 대하여 아무것도 알수 없기때문에 역시 구현된 list에서 iterator가 어떻게 되었는지 전혀 알수 없다. 그런데 어떻게 찾고서 반환되어지는 객체의 형을 알수 있을까? 다시, list 클래스는 모든 STL container와 마찬가지로 제한 해제를 한다.: 그것은 형 정의, iterator, 즉 list내부의 iterator의 정의를 제공한다. charList 가 char의 list가 된 이후로 iterator의 정의는 그러한 list인 list<char>::iterator 내부에 있고, 그것은 위의 예제와 같이 쓰인다. (각 STL container 클래스는 두가지의 iteraotr형인 '''iterator''' 와 '''const_iteraotr''' 를 정의한다. 전자는 일반적인 pointer와 같이 동작하고 후자는 pointer-to-const와 같이 동작한다. )

	다른 STL continer들을 이용해서 정확히 같은 접근을 해본다. 게다가 C++ 포인터는 STL iterator이다. 그래서 원래 배열 예제는 STL find 함수도 역시 이용할수 있다.		다른 STL continer들을 이용해서 정확히 같은 접근을 해본다. 게다가 C++ 포인터는 STL iterator이다. 그래서 원래 배열 예제는 STL find 함수도 역시 이용할수 있다.
Line 666:		Line 666:
	----		----
	[[MoreEffectiveC++]]		[[MoreEffectiveC++]]

imported>Unknown at 05:23, 7 February 2021

2021-02-07T05:23:48Z

Show changes

← Older revision		Revision as of 00:34, 29 March 2026
Line 21:		Line 21:


	DeleteMe 모호 <br />		[[DeleteMe]] 모호 <br />
	"변화한다.", 험난한 소프트웨어의 발전에 잘 견디는 클래스를 작성하라. (원문:Given that things will change, writeclasses that can withstand the rough-and-tumble world of software evolution.) "demand-paged"의 가상 함수를 피하라. 다른 이가 만들어 놓지 않으면, 너도 만들 방법이 없는 그런 경우를 피하라.(모호, 원문:Avoid "demand-paged" virtual functions, whereby you make no functions virtual unless somebody comes along and demands that you do it) 대신에 함수의 ''meaning''을 결정하고, 유도된 클래스에서 새롭게 정의할 것인지 판단하라. 그렇게 되면, 가상(virtual)으로 선언해라, 어떤 이라도 재정의 못할지라도 말이다. 그렇지 않다면, 비가상(nonvirtual)으로 선언해라, 그리고 차후에 그것을 바꾸어라 왜냐하면 그것은 다른사람을 편하게 하기 때문이다.;전체 클래스의 목적에서 변화를 유지하는지 확신을 해라.		"변화한다.", 험난한 소프트웨어의 발전에 잘 견디는 클래스를 작성하라. (원문:Given that things will change, writeclasses that can withstand the rough-and-tumble world of software evolution.) "demand-paged"의 가상 함수를 피하라. 다른 이가 만들어 놓지 않으면, 너도 만들 방법이 없는 그런 경우를 피하라.(모호, 원문:Avoid "demand-paged" virtual functions, whereby you make no functions virtual unless somebody comes along and demands that you do it) 대신에 함수의 ''meaning''을 결정하고, 유도된 클래스에서 새롭게 정의할 것인지 판단하라. 그렇게 되면, 가상(virtual)으로 선언해라, 어떤 이라도 재정의 못할지라도 말이다. 그렇지 않다면, 비가상(nonvirtual)으로 선언해라, 그리고 차후에 그것을 바꾸어라 왜냐하면 그것은 다른사람을 편하게 하기 때문이다.;전체 클래스의 목적에서 변화를 유지하는지 확신을 해라.

Line 32:		Line 32:
	이식성 있는 코드를 만들어라. 이식성 있는 프로그램의 제작은 그렇지 않은 경우보다 매우 어려운게 아니다. 그리고 눈에 보일 만큼 성능면에서 이식성 없는 코드를 고집해야 하는 경우는 희귀하다.(Item 16참고) 특정한 하드웨어를 위한 프로그램의 디자인에서도, 얼마 안있어 하드웨어 성능이 동일한 수준의 성능을 가져다 주므로, 이식성 있도록 만들어라. 이식성 있는 코드의 작성은 플랫폼 간의 변환에 쉽고, 당신의 클라라이언트 기반을 공고히 하고, 오픈 시스템의 지원에 관하여 좋다. 만약, 한 OS에서 성능이 실패해도, 쉽게 복구할수 있다.		이식성 있는 코드를 만들어라. 이식성 있는 프로그램의 제작은 그렇지 않은 경우보다 매우 어려운게 아니다. 그리고 눈에 보일 만큼 성능면에서 이식성 없는 코드를 고집해야 하는 경우는 희귀하다.(Item 16참고) 특정한 하드웨어를 위한 프로그램의 디자인에서도, 얼마 안있어 하드웨어 성능이 동일한 수준의 성능을 가져다 주므로, 이식성 있도록 만들어라. 이식성 있는 코드의 작성은 플랫폼 간의 변환에 쉽고, 당신의 클라라이언트 기반을 공고히 하고, 오픈 시스템의 지원에 관하여 좋다. 만약, 한 OS에서 성능이 실패해도, 쉽게 복구할수 있다.

	당신의 코드를 변화가 필요할때, 그 효과를 지역화(지역화:localized) 시키도록 디자인 해라. 가능한한 캡슐화 하여라:구체적인 구현은 private 하라. 광범위하게 적용해야 할곳이 있다면 이름없는(unamed) namespace나, file-static객체 나 함수(Item 31참고)를 사용하라. 가상 기초 클래스가 주도하는 디자인은 피하라. 왜냐하면 그러한 클래스는 그들로 부터 유도된 모든 클래스가 초기화 해야만 한다. - 그들이 직접적으로 유도되지 않은 경우도(Item 4참고) if-than-else을 개단식으로 사용한 RTTI 기반의 디자인을 피하라.(Item 31참고) 항상 클래스의 계층은 변화한다. 각 코드들은 업데이트 되어야만 한다. 그리고 만약 하나를 읽어 버린다면, 당신의 컴파일러로 부터 아무런 warning를 받을수 없을 것이다.		당신의 코드를 변화가 필요할때, 그 효과를 지역화(지역화:localized) 시키도록 디자인 해라. 가능한한 캡슐화 하여라:구체적인 구현은 private 하라. 광범위하게 적용해야 할곳이 있다면 이름없는(unamed) namespace나, file-static객체 나 함수(Item 31참고)를 사용하라. 가상 기초 클래스가 주도하는 디자인은 피하라. 왜냐하면 그러한 클래스는 그들로 부터 유도된 모든 클래스가 초기화 해야만 한다. - 그들이 직접적으로 유도되지 않은 경우도(Item 4참고) if-than-else을 개단식으로 사용한 [[RTTI]] 기반의 디자인을 피하라.(Item 31참고) 항상 클래스의 계층은 변화한다. 각 코드들은 업데이트 되어야만 한다. 그리고 만약 하나를 읽어 버린다면, 당신의 컴파일러로 부터 아무런 warning를 받을수 없을 것이다.

	이와 같은 내용들을 아무리 반복해서 말하곤 하지만, 대부분의 프로그래머들은 현재의 시류를 그대로 고집한다. 훌륭한 안목의 C++ 전문가가 말하는 충고에 관해서 생각해라.		이와 같은 내용들을 아무리 반복해서 말하곤 하지만, 대부분의 프로그래머들은 현재의 시류를 그대로 고집한다. 훌륭한 안목의 C++ 전문가가 말하는 충고에 관해서 생각해라.
Line 49:		Line 49:
	그 의미는 클라이언트 코드에 대하여 약간의 변화가 -delete문-결과적으로 클래스 B의 정의까지 변화해야 하는 필요성을 보여준다. 그런한 상황이 발생하면, B의 클라이언트들은 모두 재 컴파일 해야 한다. 아까, 이 필자의 충고를 따르면, 확장 코드에 대한 클라이언트의 라이브러리도 재 컴파일, 재 연결해야 한다. 이는 소프트웨어 디자인에 효과를 미틴다.		그 의미는 클라이언트 코드에 대하여 약간의 변화가 -delete문-결과적으로 클래스 B의 정의까지 변화해야 하는 필요성을 보여준다. 그런한 상황이 발생하면, B의 클라이언트들은 모두 재 컴파일 해야 한다. 아까, 이 필자의 충고를 따르면, 확장 코드에 대한 클라이언트의 라이브러리도 재 컴파일, 재 연결해야 한다. 이는 소프트웨어 디자인에 효과를 미틴다.

	DeleteMe 전체적으로 모호가 아니다, 뒤에 내용을 봐야 앞에 내용이 이해가 감.		[[DeleteMe]] 전체적으로 모호가 아니다, 뒤에 내용을 봐야 앞에 내용이 이해가 감.

	같은 주제로, 또 다른 필자의 글을 보자.		같은 주제로, 또 다른 필자의 글을 보자.
Line 520:		Line 520:

	ISO/ANSI standard for C++ 는 컴파일러가 구현될때, 벤더들의 조언이고, 책을 준비할때, 작가들이 시험해 볼 것이고, 프로그래머들이 C++에 관한 정의에 질문에 답이다. ARM이 나온 이후 C++에 가장 큰 변화를 알아 보자.		ISO/ANSI standard for C++ 는 컴파일러가 구현될때, 벤더들의 조언이고, 책을 준비할때, 작가들이 시험해 볼 것이고, 프로그래머들이 C++에 관한 정의에 질문에 답이다. ARM이 나온 이후 C++에 가장 큰 변화를 알아 보자.
	* '''새로운 개념의 추가''' : RTTI, namespace, bool, mutable과 explicit keyword, enum을 위한 오벌드(overload) 연산자 능력, 클래스 정의 내부에서 이용한 완전한 정적 클래스 멤버 초기화 증력		* '''새로운 개념의 추가''' : [[RTTI]], namespace, bool, mutable과 explicit keyword, enum을 위한 오벌드(overload) 연산자 능력, 클래스 정의 내부에서 이용한 완전한 정적 클래스 멤버 초기화 증력
	* '''템플릿(template)의 확장''' :멤버 템플릿이 허용. 이것은 탬플릿의 명시적 표현을 위한 표준 문법,함수 템플릿에서 non-type 인자들 허용 하는것, 클래스 템플릿이 그들 자신의 템플릿을 인자로 받을수 있는것 이 있다.		* '''템플릿(template)의 확장''' :멤버 템플릿이 허용. 이것은 탬플릿의 명시적 표현을 위한 표준 문법,함수 템플릿에서 non-type 인자들 허용 하는것, 클래스 템플릿이 그들 자신의 템플릿을 인자로 받을수 있는것 이 있다.
	* '''예외 핸들링의 재정의''' : 예외 스팩은 현재 컴파일 중에 더욱더 엄격하게 검사 된다. 그리고 예측할수 없는 함수는 아마도 bad_exception 예외 객체를 던진다.		* '''예외 핸들링의 재정의''' : 예외 스팩은 현재 컴파일 중에 더욱더 엄격하게 검사 된다. 그리고 예측할수 없는 함수는 아마도 bad_exception 예외 객체를 던진다.
Line 557:		Line 557:
	string 형의 디자인에 반영된 이러한 접근은-템플릿의 일반화- 표준 C++ 라이브러리를 통해서 반복되어 진다. IOStream? 그들은 템플릿이다.; 인자(type parameter)는 스트림에서 만들어지는 문자형으로 정의되어 있다. 복잡한 숫자(Complex number)? 역시 템플릿이다.;인자(type parameter)는 숫자를 어떻게 저장할지 정의되어 있다. Valarray? 템플릿이다.;인자(type parameter)는 각 배열에 최적화된다. 그리고 STL은 거의 모든 템플릿의 복합체이다. 만약 당신이 템플릿에 익숙하지 않다면, 지금 한발작 내디뎌 보아라.		string 형의 디자인에 반영된 이러한 접근은-템플릿의 일반화- 표준 C++ 라이브러리를 통해서 반복되어 진다. IOStream? 그들은 템플릿이다.; 인자(type parameter)는 스트림에서 만들어지는 문자형으로 정의되어 있다. 복잡한 숫자(Complex number)? 역시 템플릿이다.;인자(type parameter)는 숫자를 어떻게 저장할지 정의되어 있다. Valarray? 템플릿이다.;인자(type parameter)는 각 배열에 최적화된다. 그리고 STL은 거의 모든 템플릿의 복합체이다. 만약 당신이 템플릿에 익숙하지 않다면, 지금 한발작 내디뎌 보아라.

	표준 라이브러에 관하여 다른 부분도 std 이름 공간안에 모든것이 가상적으로 포함되어 있다. 표준 라이브리에서 명시적으로 그들의 이름을 표현하지 않고 쓰기 위해서는, using으로 직접 접근을 하거나 미리 using선언을 통해 접근할수 있다. (DeleteMe 모호)다행스럽게도 이러한 문법의 관리는 당신이 #include 를 사용할때마다 알맞는 헤더에 적용된다.		표준 라이브러에 관하여 다른 부분도 std 이름 공간안에 모든것이 가상적으로 포함되어 있다. 표준 라이브리에서 명시적으로 그들의 이름을 표현하지 않고 쓰기 위해서는, using으로 직접 접근을 하거나 미리 using선언을 통해 접근할수 있다. ([[DeleteMe]] 모호)다행스럽게도 이러한 문법의 관리는 당신이 #include 를 사용할때마다 알맞는 헤더에 적용된다.

	Fortunately, this syntactic administrivia is automatically taken care of when you #include the appropriate headers.		Fortunately, this syntactic administrivia is automatically taken care of when you #include the appropriate headers.
Line 620:		Line 620:
	템플릿으로의 변환에서 값으로의 전달을 reference to const 로 전달로 변화시킬 방법이 없음을 주목해라. 각 값으로의 인자 전달은 우리에게 매번 객체의 생성과파괴의 비용을 지불하게 만든다. 우리는 pass-by-reference를 사용해서, 아무런 객체의 생성과 파괴를 하지 않도록 만들어서 해당 비용을 피해야 한다.		템플릿으로의 변환에서 값으로의 전달을 reference to const 로 전달로 변화시킬 방법이 없음을 주목해라. 각 값으로의 인자 전달은 우리에게 매번 객체의 생성과파괴의 비용을 지불하게 만든다. 우리는 pass-by-reference를 사용해서, 아무런 객체의 생성과 파괴를 하지 않도록 만들어서 해당 비용을 피해야 한다.

	그렇지만 이 템플릿은 좋다, 개다가 일반화 까지 할수 있다. 시작과 끝에 연산자를 보아라. 사용된 연산자는 다르다는 것, dereferencing, prefix증가(Item 6참고), 복사(함수의 반환 값을 위해서? Item 9참고)를 위해서 쓰였다. 모든 연산자는 우리가 overload할수 있다. (DeleteMe 모호) 그래서 왜 포인터 사용하여 찾기를 제한하는가? 왜 허용하지 않는가 포인터 추가에서 이러한 연산자를 지원하기 위한 어떤 객체도 허용할수 없을까? (hy not allow any object that supports these operations to be used in addition to pointers?) 그래서 이렇게 하는것은 포인터 연산자의 built-in 의미를 찾기함수(find function)을 자유롭게 할것이다. 예를 들어서 우리는 리스트 에서 다음 리스트로의 이동을 해주는 prefix increment 연산자의 linked list객체와 비슷한 pointer를 정의할수 있다.		그렇지만 이 템플릿은 좋다, 개다가 일반화 까지 할수 있다. 시작과 끝에 연산자를 보아라. 사용된 연산자는 다르다는 것, dereferencing, prefix증가(Item 6참고), 복사(함수의 반환 값을 위해서? Item 9참고)를 위해서 쓰였다. 모든 연산자는 우리가 overload할수 있다. ([[DeleteMe]] 모호) 그래서 왜 포인터 사용하여 찾기를 제한하는가? 왜 허용하지 않는가 포인터 추가에서 이러한 연산자를 지원하기 위한 어떤 객체도 허용할수 없을까? (hy not allow any object that supports these operations to be used in addition to pointers?) 그래서 이렇게 하는것은 포인터 연산자의 built-in 의미를 찾기함수(find function)을 자유롭게 할것이다. 예를 들어서 우리는 리스트 에서 다음 리스트로의 이동을 해주는 prefix increment 연산자의 linked list객체와 비슷한 pointer를 정의할수 있다.

	이것이 STL iterator 뒤에 숨겨진 개념이다. Iterator는 STL container가 사용하기 위하여 pointer 비슷하게 설계된 객체이다. 그들은 Item 28의 스마트 포인터의 사촌격인 셈이다. 그렇지만 스마트 포인터는 STL의 iterator가 하는 것에 비하여 조금더 모호한 경향이 있다. 그렇지만 기술적 관점에서 그들은 같은 기술을 이용해서 구현된다.		이것이 STL iterator 뒤에 숨겨진 개념이다. Iterator는 STL container가 사용하기 위하여 pointer 비슷하게 설계된 객체이다. 그들은 Item 28의 스마트 포인터의 사촌격인 셈이다. 그렇지만 스마트 포인터는 STL의 iterator가 하는 것에 비하여 조금더 모호한 경향이 있다. 그렇지만 기술적 관점에서 그들은 같은 기술을 이용해서 구현된다.