항목 26: 변수 정의는 늦출 수 있는 데까지 늦추는 근성을 발휘하자

사용자 정의 타입의 변수를 정의하면(즉 메모리를 할당하면), 반드시 따라오는 비용이 있다.

-> 생성자 호출 비용, 소멸자 호출 비용

 

만약 변수를 만들고 사용하지 않아도 들어가는 필수비용이다.

 

변수를 만들고 사용 안할 경우가 있나? 싶은데 이런 경우가 있다.

 

 

 

 

변수 정의를 늦게 하면(진짜 필요해질 떄까지 정의를 미루면)

생성자와 소멸자 비용을 아낄 수 있다.

 

위 코드의 흠을 잡으라면, encrypted가 기본생성자를 호출한다는 것이다. 어짜피 나중에 값이 들어갈껀데, 이땐 대입으로 넣을 것이다.

 

초기화 vs 대입 이면 초기화가 더 좋음(항목 4 참고)

 

비밀번호를 암호화하는 함수가 하나 있다고 가정하고

 

 

이렇게 쓰는 것 보다

 

 

이렇게 쓰는 것이 훨씬 좋다. 즉 미룰 수 있을 때 까지 미루라는 말은

 

어떤 변수를 사용해야 할 때가 오기 전 + 변수의 초기화 인자를 손에 넣기 전까지 정의를 늦추라는 말이다.

 

 

좋다. 그럼 루프안에선 어떻게함? 블록이 재실행될 때 마다 블록 안에 변수 정의가 있으면 새로 생성될 것이고 이 관점에선 루프 밖에다가 먼저 변수를 정의하는게 좋은 것 같은데, 변수 정의를 최대한 늦춘다고 하면 블록 내부에서 변수를 사용해야하기 직전에 변수를 정의할 것이다.

 

A방법

 

Widget w;

for(int i=0; i<n; ++i)

{

w = i에 따라 달라지는 값..;

…

}

 

 

• A방법 : 생성자 1번 + 소멸자 1번 + 대입 n번
• B방법 : 생성자 n번 + 소멸자 n번

 

대입 cost < 생성자 cost + 소멸자 cost 인 경우 => A방법

대입 cost > 생성자 cost + 소멸자 cost 인 경우 => B방법

 

클래스의 특징에 따라 선택하면 되는데, 하나 생각할 부분이 있다.

 

A방법을 쓰면 w의 유효범위가 지역 전체가 되고, B방법을 쓰면 w의 유효범위가 루프 내부가 된다.

 

보통 유효범위가 넓을수록 프로그램의 이해도가 떨어지고, 유지보수가 힘들어진다.

그래서 정리하자면

===============================================

• 대입 cost < 생성자 cost + 소멸자 cost
• 전체 코드에서 수행 성능에 민감하다. => A방법
• 수행 성능에 큰 영향이 없다 => B방법

 

• 대입 cost > 생성자 cost + 소멸자 cost => B방법

===============================================

 

 

• 변수 정의는 늦출 수 있을 때 까지 늦추자. 프로그램이 더 깔끔해지고 효율도 좋아진다.