MoreEffectiveC++/Efficiency - 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 76:		Line 76:
	// 구현되었다고 생각하자		// 구현되었다고 생각하자
	...		...
	cout << s[3]; // operator []를 호출해서 s[3]을 읽는다.(read)		cout << s[3]; // operator []를 호출해서 s[3]을 읽는다.(read)
	s[3] = 'x'; // operator []를 호출해서 s[3]에 쓴다.(write)		s[3] = 'x'; // operator []를 호출해서 s[3]에 쓴다.(write)
	첫번째 operator[]는 문자열을 읽는 부분이다,하지만 두번째 operator[]는 쓰기를 수행하는 기능을 호출하는 부분이다. 여기에서 '''읽기와 쓰기를 구분'''할수 있어야 한다.(distinguish the read all from the write) 왜냐하면 읽기는 refernce-counting 구현 문자열로서 자원(실행시간 역시) 지불 비용이 낮고, 아마 저렇게 스트링의 쓰기는 새로운 복사본을 만들기 위해서 쓰기에 앞서 문자열 값을 조각내어야 하는 작업이 필요할 것이다.		첫번째 operator[]는 문자열을 읽는 부분이다,하지만 두번째 operator[]는 쓰기를 수행하는 기능을 호출하는 부분이다. 여기에서 '''읽기와 쓰기를 구분'''할수 있어야 한다.(distinguish the read all from the write) 왜냐하면 읽기는 refernce-counting 구현 문자열로서 자원(실행시간 역시) 지불 비용이 낮고, 아마 저렇게 스트링의 쓰기는 새로운 복사본을 만들기 위해서 쓰기에 앞서 문자열 값을 조각내어야 하는 작업이 필요할 것이다.

Line 200:		Line 200:

	하지만, lazy evaluation이 치룬 시간이 오직 저런 상태일 뿐이라면, "엄청난 계산을 요구한다"라는 문제가 더 커질것이라고 생각하기는 어렵다.의 필요성이 좀더 일반적인 시나리오는 우리가 오직 계산에서의 ''일부''가 필요한 경우이다. 예를 들자면 우리가 m3를 m1과 m2의 합으로 초기화 했다고 가정하고 다음과 같은 코드가 있다면		하지만, lazy evaluation이 치룬 시간이 오직 저런 상태일 뿐이라면, "엄청난 계산을 요구한다"라는 문제가 더 커질것이라고 생각하기는 어렵다.의 필요성이 좀더 일반적인 시나리오는 우리가 오직 계산에서의 ''일부''가 필요한 경우이다. 예를 들자면 우리가 m3를 m1과 m2의 합으로 초기화 했다고 가정하고 다음과 같은 코드가 있다면
	cout << m3[4]; // m3의 4번째 열만을 요구한다.		cout << m3[4]; // m3의 4번째 열만을 요구한다.
	확실히 우리는 이제 lazy 상태를 벗어나야 함을 알수 있다.-우리는 m3의 4번째 열에 대하여 계산된 값을 가지고 있어야 한다. 그러나, 역시나 너무나 지나친 것이다. 우리는 m3의 4번재 열을 계산해야만 하는건 말할 필요도 없다.:m3는 그것이 필요해지기 전까지는 계산할필요가 없다. 하지만 행운으로 그렇게 할 필요가 없을것이다.		확실히 우리는 이제 lazy 상태를 벗어나야 함을 알수 있다.-우리는 m3의 4번째 열에 대하여 계산된 값을 가지고 있어야 한다. 그러나, 역시나 너무나 지나친 것이다. 우리는 m3의 4번재 열을 계산해야만 하는건 말할 필요도 없다.:m3는 그것이 필요해지기 전까지는 계산할필요가 없다. 하지만 행운으로 그렇게 할 필요가 없을것이다.

Line 257:		Line 257:
	얻어오는 과정		얻어오는 과정

	cubes[employeeName] = cubicle; // 추가		cubes[employeeName] = cubicle; // 추가
	return cubicle;		return cubicle;
	}		}
Line 274:		Line 274:
	class DynArray { ... };		class DynArray { ... };

	DynArray<double> a; // 이런 관점에서 a[0]은 합법적인		DynArray<double> a; // 이런 관점에서 a[0]은 합법적인
	// 배열 인자이다.		// 배열 인자이다.
	a[22] = 3.5; // a는 자동적으로 확장되었으며,		a[22] = 3.5; // a는 자동적으로 확장되었으며,
	// 현재는 0-22까지의 영역을 가진다.		// 현재는 0-22까지의 영역을 가진다.

	a[32] = 0; // 다시 확장되며 이제 0-32까지다.		a[32] = 0; // 다시 확장되며 이제 0-32까지다.
	어떻게 DynArray 객체가 필요할때 마다 스스로 확장되는 걸까? 곧장 생각할수 있는건 그것이 새로운 메모리가 필요될때만 할당되고는 것이다 이런것 처럼 말이다.		어떻게 DynArray 객체가 필요할때 마다 스스로 확장되는 걸까? 곧장 생각할수 있는건 그것이 새로운 메모리가 필요될때만 할당되고는 것이다 이런것 처럼 말이다.
	templace<class T>		templace<class T>
	T& DynArray<T>::operator[](int index)		T& DynArray<T>::operator[](int index)
	{		{
	if (index < 0) {		if (index < 0) {
Line 295:		Line 295:
	over-eager evaluation(선연산,미리연산) 전술은 이 것에대한 답을 제시한다.:만약 우리가 index i로서 현재의 배열상의 크기를 늘리려면, locality of reference 개념은 우리가 아마 곧 index i보다 더 큰 공간의 필요로 한다는걸 이야기 한다. 이런 두번째 (예상되는)확장에 대한 메모리 할당의 비용을 피하기 위해서는 우리는 DynArray의 i의 크기가 요구되는 것에 비해서 조금 더 많은 양을 잡아서 배열의 증가에 예상한다. 그리고 곧 있을 확장에 제공할 영역을 준비해 놓는 것이다. 예를 들어 우리는 DynArray::operator[]를 이렇게 쓸수 있다.		over-eager evaluation(선연산,미리연산) 전술은 이 것에대한 답을 제시한다.:만약 우리가 index i로서 현재의 배열상의 크기를 늘리려면, locality of reference 개념은 우리가 아마 곧 index i보다 더 큰 공간의 필요로 한다는걸 이야기 한다. 이런 두번째 (예상되는)확장에 대한 메모리 할당의 비용을 피하기 위해서는 우리는 DynArray의 i의 크기가 요구되는 것에 비해서 조금 더 많은 양을 잡아서 배열의 증가에 예상한다. 그리고 곧 있을 확장에 제공할 영역을 준비해 놓는 것이다. 예를 들어 우리는 DynArray::operator[]를 이렇게 쓸수 있다.
	template<class T>		template<class T>
	T& DynArray<T>::operator[](int index)		T& DynArray<T>::operator[](int index)
	{		{
	if (index < 0) 예외를 던진다.;		if (index < 0) 예외를 던진다.;
Line 305:		Line 305:
	}		}
	이 함수는 두번 충분한 양의 배열을 각각 필요할때 할당한다. 만약 우리가 앞서 이야기한 쓰임의 시나리오대로 진행 된다면, 아마 DynArray는 그것이 두번의 논리적 크기의 확장을 할지라도 오직 메모리를 한번만 할당할 것이다.:		이 함수는 두번 충분한 양의 배열을 각각 필요할때 할당한다. 만약 우리가 앞서 이야기한 쓰임의 시나리오대로 진행 된다면, 아마 DynArray는 그것이 두번의 논리적 크기의 확장을 할지라도 오직 메모리를 한번만 할당할 것이다.:
	DynArray<double> a; // 오직 a[0]만이 유효하다.		DynArray<double> a; // 오직 a[0]만이 유효하다.
	a[22] = 3.5; // 현재 index 44정도의 저장 공간을		a[22] = 3.5; // 현재 index 44정도의 저장 공간을
	// 할당하며 a의 논리적 공간은 23이다.		// 할당하며 a의 논리적 공간은 23이다.
	a[32] = 0; // a의 논리적 공간은 이제 a[32]이다. 하지만		a[32] = 0; // a의 논리적 공간은 이제 a[32]이다. 하지만
	// 44의 저장공간이 있기에 확장하지 않는다.		// 44의 저장공간이 있기에 확장하지 않는다.
	만약 다시 확장이 필요하다면 44보다 크지 않는다면, new에 의한 높은 비용을 치루지 않는다.		만약 다시 확장이 필요하다면 44보다 크지 않는다면, new에 의한 높은 비용을 치루지 않는다.
Line 333:		Line 333:
	// 다음 함수는 str안에서 ch가 몇게 있는가 반환한다.		// 다음 함수는 str안에서 ch가 몇게 있는가 반환한다.
	size_t countChar(const string& str, char ch);		size_t countChar(const string& str, char ch);
	char buffer[MAX_STRING_LEN];		char buffer[MAX_STRING_LEN];
	char c;		char c;
	// string과 char를 받아 들인다. setw 는 글자를 읽을때		// string과 char를 받아 들인다. setw 는 글자를 읽을때
Line 348:		Line 348:
	void uppercasify(string& str); // str의 모든 글자를 대문자료 바꾼다.		void uppercasify(string& str); // str의 모든 글자를 대문자료 바꾼다.
	글자 세기(charter-counting)예제에서 char 배열은 성공적으로 countChar로 전달된다. 그렇지만 이것과 같은 함수에서는 에러가 발생한다. 다음과 같은 코드 말이다.		글자 세기(charter-counting)예제에서 char 배열은 성공적으로 countChar로 전달된다. 그렇지만 이것과 같은 함수에서는 에러가 발생한다. 다음과 같은 코드 말이다.
	char subtleBookPlug[] = "Effective C++";		char subtleBookPlug[] = "Effective C++";
	uppercasify(subtleBookPlug); // 에러다!		uppercasify(subtleBookPlug); // 에러다!
	어떠한 임시인자(temporary)도 만들어 지지 않았다. 왜 만들어 지지 않은 걸까?		어떠한 임시인자(temporary)도 만들어 지지 않았다. 왜 만들어 지지 않은 걸까?

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 11:		Line 11:
	DeleteMe ) 해당 스크립트의 뒷부분이 제대로 이해가 안간다. 당연한 내용을 꼬아 쓴것 같은데, 차후 수정 시도 하겠음 --상민		DeleteMe ) 해당 스크립트의 뒷부분이 제대로 이해가 안간다. 당연한 내용을 꼬아 쓴것 같은데, 차후 수정 시도 하겠음 --상민

	'''80-20 규칙''' 이란? 프로그램의 80%의 리소스가 20%의 코드에서 쓰여진다.:실행 시간의 80%가 대략 20%의 코드를 소모한다;80%의 메모리는 어떤 20%의 코드에서 쓴다.;80%의 disk 접근은 20%의 코드에서 이루어진다.:80%의 소프트웨어 유지의 노력은(maintenance effort)는 20%의 코드에 쏟아 부어진다.		'''80-20 규칙''' 이란? 프로그램의 80%의 리소스가 20%의 코드에서 쓰여진다.:실행 시간의 80%가 대략 20%의 코드를 소모한다;80%의 메모리는 어떤 20%의 코드에서 쓴다.;80%의 disk 접근은 20%의 코드에서 이루어진다.:80%의 소프트웨어 유지의 노력은(maintenance effort)는 20%의 코드에 쏟아 부어진다.<br />
	80-20 규칙은 수많은 기계에서, 운영체제(Operating System)에서, 그리고 어플리케이션에서 적용된다. 80-20 규칙은 단지 재미있는 표현보다 더 많은 의미가 있다.;그것은 광범위하고, 실질적인 개념이 필요한 시스템의 성능(능률)에 개선 대한 기준점을 제시한다.		80-20 규칙은 수많은 기계에서, 운영체제(Operating System)에서, 그리고 어플리케이션에서 적용된다. 80-20 규칙은 단지 재미있는 표현보다 더 많은 의미가 있다.;그것은 광범위하고, 실질적인 개념이 필요한 시스템의 성능(능률)에 개선 대한 기준점을 제시한다.

Line 20:		Line 20:
	많은 사람들이 병목현상(bottleneck)에 관한 해결책에 고심한다. 경험에 따른 방법, 직관력, tarot 카드이용(운에 맏기기) 그리고 Ouija(점괘를 나타내는 널판지의 상표명, 즉 점보기) 보드를 사용 하기도 하고, 소문이나 잘못, 올바르지 않은 메모리 할당, 충분하지 않은 최적화를 한 컴파일러, 혹은 치명적인 순환 구문을 만들어내기 위해 어셈블리 언어를 사용한 돌대가리 메니저들의 메니저들. 이러한 사정들은 일반적으로 멸시의 비웃음을 동반하고, 그들의 예언은 솔직히 잘못된 것이다.		많은 사람들이 병목현상(bottleneck)에 관한 해결책에 고심한다. 경험에 따른 방법, 직관력, tarot 카드이용(운에 맏기기) 그리고 Ouija(점괘를 나타내는 널판지의 상표명, 즉 점보기) 보드를 사용 하기도 하고, 소문이나 잘못, 올바르지 않은 메모리 할당, 충분하지 않은 최적화를 한 컴파일러, 혹은 치명적인 순환 구문을 만들어내기 위해 어셈블리 언어를 사용한 돌대가리 메니저들의 메니저들. 이러한 사정들은 일반적으로 멸시의 비웃음을 동반하고, 그들의 예언은 솔직히 잘못된 것이다.

	(DeleteMe 이후 영어 해석이 너무 모호하다. 사실 내용을 잘 이해를 못했다. 차후 고치자. 이 전도 마찬가지)		(DeleteMe 이후 영어 해석이 너무 모호하다. 사실 내용을 잘 이해를 못했다. 차후 고치자. 이 전도 마찬가지)<br />
	대부분 프로그래머들은 그들의 프로그램에 관한 특성에 관하여 멍청한 직관력을 가지고 있다. 왜냐하면 프로그램 성능의 특징은 아주 직관적이지 못하다. 결과적으로 남에 눈에는 띄지 않고 말할수 많은 노력이 성능 향상을 위해 프로그램의 관련된 부분에 쏟아 부어 진다. 예를들어서 아마, 계산을 최소화 시키는 알고리즘과 데이터 구조가 프로그램에 적용 되다. 그렇지만 만약에 입출(I/O-bound)력 부분 적용된다면 저것은 허사가 된다. 증가되는 I/O 라이브러리는 아마 컴파일러에 의하여 바뀐 그 코드에 의해 교체될것이다. 그렇지만, 프로그램이 CPU-bound에 대한 사용이라면 또 이건 별로 중요한 포인터(관점)이 되지 않는 것이다.		대부분 프로그래머들은 그들의 프로그램에 관한 특성에 관하여 멍청한 직관력을 가지고 있다. 왜냐하면 프로그램 성능의 특징은 아주 직관적이지 못하다. 결과적으로 남에 눈에는 띄지 않고 말할수 많은 노력이 성능 향상을 위해 프로그램의 관련된 부분에 쏟아 부어 진다. 예를들어서 아마, 계산을 최소화 시키는 알고리즘과 데이터 구조가 프로그램에 적용 되다. 그렇지만 만약에 입출(I/O-bound)력 부분 적용된다면 저것은 허사가 된다. 증가되는 I/O 라이브러리는 아마 컴파일러에 의하여 바뀐 그 코드에 의해 교체될것이다. 그렇지만, 프로그램이 CPU-bound에 대한 사용이라면 또 이건 별로 중요한 포인터(관점)이 되지 않는 것이다.

Line 211:		Line 211:
	m3 = m1 + m2; // m3가 m1,m2의 합인걸 기억하라		m3 = m1 + m2; // m3가 m1,m2의 합인걸 기억하라
	m1 = m4; // 이제 m3는 m2와 과거 m1의 합이 된다.		m1 = m4; // 이제 m3는 m2와 과거 m1의 합이 된다.
	그러므로 몇가지의 m1에 대한 할당이 m3를 변화시키지 않는다는 확신을 가지고 있어야 한다. Matrix~~<~~int~~>~~의 내부에 할당된 operator 내부에 m3의 값이 m1의 계산 이전에 계산되어 있거나, m1의 과거 값에 대한 복사본을 가지고 있고 m3는 그것에 의존해야 한다. 다른 함수들도 이러한 행렬의 변경을 위하여 다른 형식의 함수들도 이런 비슷한 것을 감안해야 할것이다.		그러므로 몇가지의 m1에 대한 할당이 m3를 변화시키지 않는다는 확신을 가지고 있어야 한다. Matrix<int>의 내부에 할당된 operator 내부에 m3의 값이 m1의 계산 이전에 계산되어 있거나, m1의 과거 값에 대한 복사본을 가지고 있고 m3는 그것에 의존해야 한다. 다른 함수들도 이러한 행렬의 변경을 위하여 다른 형식의 함수들도 이런 비슷한 것을 감안해야 할것이다.

	각 값 간의 의존성과,;데이터 구조의 유지를 위하여, 값들, 의존성이나 두가지의 결합 방법을 저장해야 한다.; 그리고 많은 수치 계산이 필요한 분야에서 복사, 더하기 할당, 같은 operator의 overload 것이 필요하다. 반면에 lazy evaluation의 적용은 프로그램 실행중에서 정말 많은 시간들과 많은 자원들을 아낄수 있다. 그래서 lazy evaluation의 존재를 정당화 시켜 줄것이다.		각 값 간의 의존성과,;데이터 구조의 유지를 위하여, 값들, 의존성이나 두가지의 결합 방법을 저장해야 한다.; 그리고 많은 수치 계산이 필요한 분야에서 복사, 더하기 할당, 같은 operator의 overload 것이 필요하다. 반면에 lazy evaluation의 적용은 프로그램 실행중에서 정말 많은 시간들과 많은 자원들을 아낄수 있다. 그래서 lazy evaluation의 존재를 정당화 시켜 줄것이다.

imported>Unknown at 05:23, 7 February 2021

2021-02-07T05:23:48Z

Show changes