Question
오늘은 별로 흥미진진한 내용은 아니네요. 역시 뉴스그룹에서 가져왔습니다. ((
comp.lang.c++.moderated:prog output?))
#include "iostream.h"
void main(void)
{
const int i = 10;
int *p;
p = const_cast(&i);
*p = 111;
cout << i << " " << *p;
}
/*
output:
10 111
*/
질문은...
- 왜 i 와 *p의 출력이 다르게 나오는가?
Answer
뉴스그룹의 친절한 답변자들 모두 답에 앞서 코드에 있는 문제들을 지적하네요.
- 표준 헤더를 쓸 생각이었다면 iostream.h가 아니라 iostream을 써야 할것이다.
- 또한 표준 헤더라면 <>괄호를 사용하여야 한다.
- main의 리턴 타입은 int이다.
모두 적용하면 다음과 같이 되겠군요.
#include
int main()
{
const int i = 10;
int *p;
p = const_cast(&i);
*p = 111;
std::cout << i << " " << *p;
}
진짜 중요한 문제의 답은 간단합니다.
const 객체를 수정하는 코드의 결과는 정의되어 있지 않으므로(undefined behavior) 컴파일러는 위 프로그램에서 어떤 값이라도 출력할 수 있습니다.
너무 간단하죠? 참고로 undefined behavior에 대해 얼마전
DDJ에 올라온 Pete Becker의
Living By the Rules에서 인용해봅니다.
Violations of semantic rules that are not diagnosable semantic rules result in undefined behavior; that is, the C++ Standard doesn't impose any requirement on what a compiler does when faced with such code. When referring to this, please don't use the abominable wording "This program invokes undefined behavior." The correct phrasing is "The behavior of this program is undefined." And please keep in mind that undefined behavior means only that the C++ Standard doesn't say what the code in question does. It does not mean that compilers are obliged to do nasty things like set fire to your hard drive. Often, the best way to write code that takes maximal advantage of the hardware it will run on is to use code constructs whose behavior is undefined, but well understood. For example, if you really need speed, instead of testing whether an integer value is greater than or equal to zero and less than some upper limit, you can convert it to an unsigned integer type with the same number of bits and test whether the result is greater than the upper limit. On most architectures, converting the value doesn't change any bits, so it doesn't require any code; negative values are simply treated as large unsigned values, which will always exceed the limit. The behavior of that code is formally undefined, but it works. Except when it doesn't. Test for it.
마지막 부분에 있는 undefined behavior의 사용예를 보니 간단하면서도 아이디어가 좋네요. 실제로는 가독성이라던가 유지 보수성을 감안했을땐 사용하지 않는게 좋겠죠? :-)
Comments
Post a Comment