[Effective C++] 변수 정의는 늦출 수 있는 데까지 늦추는 근성을 발휘하자

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

 

생성자 혹은 소멸자를 끌고 다니는 타입으로 변수를 정의하면 반드시 물게 되는 비용이 두 개 있습니다.

하나는 프로그램 제어 흐름이 변수의 정의에 닿을 때 생성자가 호출되는 비용이고, 또 하나는 그 변수가 유효범위를 벗어날 때 소멸자가 호출되는 비용입니다.

 

변수가 정의됐으나 사용되지 않은 경우에도 비용이 부과됩니다.

밑에 예제가 있습니다.

 

// 이 함수는 "encrypted" 변수를 너무 일찍 정의해 버립니다.
std::string encryptPassword(const std::string& password)
{
    using namespace std;
 
    string encrypted;
 
    if(password.length() < MinimumPasswordLength)
    {
        throw logic_error("Password is too short");
    }
 
    ...                                                                // 주어진 비밀번호를 암호화하여 encrypted 변수에 넣는 데 필요한 일들을 여기서 합니다.
 
    return encrypted;
}

 

encrypted 객체가 이 함수에서 완전히 안 쓰인다고는 말할 수 없지만, 예외가 발생되면 이 변수는 분명히 사용되지 않게 됩니다. 이런것을 확인했으니 encrypted 변수를 정의하는 일은 꼭 필요해지기 전까지 미루는 편이 좋겠습니다.

 

// 이 함수는 "encrypted" 변수가 진짜로 필요해질 때까지 정의를 미룹니다.
std::string encryptPassword(const std::string& password)
{
    using namespace std;
 
    if(password.length() < MinimumPasswordLength)
    {
        throw logic_error("Password is too short");
    }
 
    string encrypted;
 
    ...                                                                // 주어진 비밀번호를 암호화하여 encrypted 변수에 넣는 데 필요한 일들을 여기서 합니다.
 
    return encrypted;
}

 

이번 항목의 제목에 적힌 '늦출 수 있는 데까지'의 진짜 뜻은 어떤 변수를 사용해야 할 때가 오기 전까지 그 변수의 정의를 늦추는 것은 기본이고, 초기화 인자를 손에 넣기 전까지 정의를 늦출 수 있는지도 둘러봐야 한다는 것입니다. 이렇게 해야 쓰지도 않을 객체가 만들어졌다 없어지는 일이 생기지 않으며, 불필요한 기본 생성자 호출도 일어나지 않습니다. 덤으로, 누가 보아도 그 변수의 의미가 명확한 상황에서 초기화가 이루어지기 때문에, 변수의 쓰임새를 문서화하는 데도 큰 도움이 됩니다.

 

루프에서 사용할 경우는 어떨까요?

예시를 보시죠.

 

// A 방법 : 루프 바깥쪽에 정의
 
Widget w;
for(int  i = 0; i < n; i++)
{
    w = i에 따라 달라지는 값;
    ...
}

 

// B 방법 : 루프 안쪽에 정의
 
for(int  i = 0; i < n; i++)
{
    Widget w(i에 따라 달라지는 값);
    ...
}

 

이제 Widget 객체에 들어가는 연산을 기준으로 해서 두 방법에 걸리는 비용을 정리해보겠습니다.

 

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

B 방법 : 생성자 n번 + 소멸자 n번

 

클래스 중에는 대입에 들어가는 비용이 생성자-소멸자 쌍보다 적게 나오는 경우가 있는데, Widget 클래스가 이런 종류에 속한다면 A 방법이 일반적으로 훨씬 효율이 좋습니다. 이 차이는 n이 커질 때 특히 더 커집니다. 반면, 그렇지 않은 경우엔 B 방법이 아마 더 좋을것입니다.

 

A 방법을 쓰면 w라는 이름을 볼 수 있는 유효범위가 B 방법을 쓸 때보다 넓어지기 때문에, 프로그램의 이해도와 유지보수성이 역으로 안 좋아질 수도 있습니다.

 

두 가지를 체크해보세요!

1. 대입이 생성자-소멸자 쌍보다 비용이 덜 들고

2. 전체 코드에서 수행 성능에 민감한 부분을 건드리는 중이라고 생각하지 않는다.

 

이런 경우 B 방법을 채택하시면 됩니다!

 

꼭 잊지 말아야 할 것!

변수 정의는 늦출 수 있을 때까지 늦춥시다. 프로그램이 더 깔끔해지며 효율도 좋아집니다.