[Effective Modern C++] 항목 5

Effective Modern C++ 책을 보며 정리하는 포스팅

현재 수준에 감당 되는 것만 추가 공부하여 정리

 

auto 사용 시, 장점

auto를 잘 활용하면 개발 코드의 양이 줄어든다..

또한, 직접 지정했을 때 겪게 되는 정확성 문제와 성능 문제도 방지할 수 있다.

 

 

 

항목 5. 명시적 형식 선언보다는 auto를 선호하라.

 

1.

auto 변수의 형식은 해당 초기값으로 부터 deduction된다.

따라서 초기값을 반드시 제공 해야한다.

 

int a; //OK

auto b; //compile error

auto c = 0; //OK

위 코드는 지역 변수 선언이다.

a 변수는 컴파일러에 따라 초기화가 0으로 되거나, 쓰레기값이 적재되기도 한다.

-> C/C++이 퍼포먼스에 최척화된 언어라고는 하나 꼭 초기화를 해주자..

(초기화 하는 퍼포먼스까지 고려하여 개발자에게 책임을 넘긴 것이다..)

 

b 변수는 auto 변수 이므로 초기값이 없어 deduction 할 수 없어 컴파일러가 오류이다.

 

c 변수는 정상이다.

 

결론.

개발자가 실수로 초기화를 누락하는 일이 없어지는 장점!

 

 

2.

auto는 형식 deduction을 사용하므로..

컴파일러만 알던 형식을 지정할 수도 있다.

//std::fuction을 사용할 경우
std::function<bool(const std::unique_ptr<Widget>&, const std::unique_ptr<Widget>&)>
    comp = [] (const std::unique_ptr<Widget>& p1, const std::unique_ptr<Widget>& p2) {
    return *p1 < *p2;
};

//클로저를 담는 변수 comp
auto comp = [] (const std::unique_ptr<Widget>& p1, const std::unique_ptr<Widget>& p2) {
    return *p1 < *p2;
};

//람다 표현식의 매개변수에도 auto를 적용할 수 있다.
auto comp = [] (const auto& p1, const auto& p2) {
    return *p1 < *p2;
};

위에서 아래로 갈 수록 코드가 간결해진다.

클로저를 담는 변수에도 auto를 사용할 수 있다.

람다 표현식의 매개 변수에도 auto를 적용할 수 있다.

 

결론.

정말 다양한 형식에 호환이 가능하다.

코드량을 획기적으로 단축

 

<참고>

람다와 클로저의 차이는..

클래스와 클래스 인스턴스의 차이와 동일하다.

람다 표현식이 인스턴스화 된 것이 클로저이다.

(람다 표현식은 코드 상에서만 존재하며, 런타임 시에는 인스턴스화 된 클로저가 존재한다.)

람다 : 람다 표현식의 준말

람다 표현식 : 위 코드 상 rvalue

람다 표현식의 런타임 결과는 오브젝트 생성이며 그 오브젝트가 클로저

-스콧 마이어-

 

 

3.

std::vector<int> v;

//첫번째 개발자, unsigned라고 지정
unsigned sz = v.size();

//두번째 개발자, auto 사용
auto sz = v.size();

v.size()의 실제 반환 형식은 std::vector<int>::size_type 이다.

 

첫번째 개발자의 문제점

첫번째 개발자는 size 이므로 unsigned 형식이 충분하다고 생각하였다..

32비트 windows 에서는 unsigned와 std::vector<int>::size_type이 같은 크기 이지만..

64비트 windows 에서는 unsigned (4바이트), std::vector<int>::size_type은 8바이트 이다...

-> 문제 발생 가능..

 

두번째 개발자는 auto를 사용하여 이러한 문제를 신경 쓸 필요가 없다..

-> 코드의 유지보수성 측면에서 효율적이다.

 

 

std::unordered_map<std::string, int> um;

//첫번째 개발자..
for(const std::pair<std::string, int>& p : um) {
    ...
}

//두번째 개발자..
for(const auto& p : um) {
    ...
}

std::unordered_map의 key는 사실 const이다..

따라서 hash table에 담긴 std::pair 의 형식은 std::pair<std::string, int>가 아니라..

std::pair<const std::string, int> 이다..

 

그래서..

컴파일러는 std::pair<const std::string, int>에서.. std::pair<std::string, int>로 변환작업을 계속 해준다.

(루프 각 반복에서 um의 각 객체를 복사하고 참조 p를 um을 복사 생성한 임시 객체에 묶으며.. 또한 암묵적 캐스팅이 일어난다.. 임시 객체는 루프의 반복 끝에서 파괴)

 

결론.

기대하지 않은 암묵적 변환을 없앨 수 있다.

 

 

실무에서 auto를 쓴다..?

물론 auto를 쓰는 건 선택사항이다..

형식 추론 기술이 대규모 업계 수준 코드 기반의 작성 및 유지보수 능력과 충돌하지 않는다.

 

 

auto를 쓰면 형식을 바로 알 수 없기 때문에.. 코드가독성이 안 좋다고 생각할 수 있지만..

그건 IDE의 기능으로 완화되는 경우가 많다..