http://www.swallowstudio.com/index.php?pl=77

Prefer ++i to i++.

i++ requires a compiler to remeber the original value, while ++i does not. Some might argue that modern compilers can optimize increments, say converting i++ to ++i if the original value of i is not needed. This is not true in case of increments of classes, though int and complex type can be optimized each of which is fully known to the compilers.

언제 컴파일러가 사후증가를 최적화 하는가?

“i++”과 같이 사후증가를 사용하면서 반환값을 사용하지 않을 수 있다. 그러면, 컴파일러는 이것을 눈치채고, 간단히 사후증가를 사전증가로 다시 작성하여 최적화 하는 것을 허락할까?

대답은 “아니오, 일반적으로 그렇지 않습니다”이다. 컴파일러가 불필요한 사후증가를 사전증가로 다시 작성하여 최적화를 허락하는 유일한 경우는, 사후증가의 대상이 내장되어 있는 int와 complex 같은 표준형일 때이다. 이들은 표준이므로, 컴파일러가 의미상 용도를 이해하고 있기 때문이다.

반면에, 클래스형일 경우, 컴파일러는 사전증가와 사후증가의 실제 의미상 용도를 모르므로, 그 두가지가 같은 행동을 하는 것인지 판단할 수 없다. 만약 두 함수가 같은 행동을 하지 않는다면 정말 최악의 경우일 것이고, 다른 의미를 가지도록 이를 작성한 프로그래머는 바로 제재를 당할 것이다. 하지만, 일반적인 상황에서 프로그래머가 항상 착실하다고 생각할 수는 없기 때문에, 컴파일러가 마음대로 처리할 수는 없다.

강제로 컴파일러에게 클래스형에 대해 ‘사전’과 ‘사후’의 관계를 알게 하는 방법은 있다. 사전증가를 호출하는 사후증가의 정규 형태를 inline으로 선언하여, 컴파일러가 함수 호출 경계(inline 지시어에 관련)를 가로질로 볼 수 있고, 사용하지 않는 임시 개체를 판별할 수 있도록 구현하는 것이다. 하지만, inline을 사용하는 것이 만병 통치약은 아니므로 별로 추천하고 싶지는 않다. 컴파일러에 의해 무시될 수도 있고, 다른 문제와 연결되어 다르게 생성될 수도 있다. 더 쉬운 해결책은, 원래의 값을 사용하지 않는 경우, 간단히 사전증가를 사용하는 습관을 익혀서 최적화가 필요하지 않도록 하는 것이다.