윈도우 프로그래밍을 할 때, 디버그 모드에서는 잘 돌아가던 프로그램이 릴리즈 모드에서 이상한 증상을 보이면 참 난감하다. 물론 Visual Studio 2005는 릴리즈 모드에서도 디버깅이 가능한 것처럼 보이지만 실제로 해보면 코드추적(tracing)도 잘 안 되고, 변수값도 이상하게 찍히기 때문에 별로 도움이 안 된다.
인자로 넘긴 문자열을 Visual Studio 출력창에 찍어주는 OutputDebugString 함수를 쓰면 예전에 printf()로 하던 것처럼 디버깅할 수 있다. 특히 DebugView라는 프로그램을 실행하면 이 함수의 출력값을 -Visual Studio 출력창이 아닌- 윈도우 화면으로 확인할 수 있기 때문에 다른 사람의 컴퓨터에서 문제가 생겼을 때 아주 유용하다.
아래와 같이 함수를 하나 만들어 두면,
이렇게 사용할 수 있다. 단, 개발 완료 후 최종 사용자에게 배포할 때에는 이 OutputDebugString()이 호출되지 않도록 주의해야 한다. 너무나 당연한 것이, 입장을 바꾸어 내가 디버깅을 하려는데 DebugView 창에 듣도 보도 못한 프로그램이 이상한 메시지를 쏟아놓고 있으면 얼마나 짜증이 나겠는가 말이다. 국내의 한 상용 프로그램은 그 처리를 제대로 안 한 덕분에, 내가 아는 어떤 분으로부터 걸핏하면 "디버그 계의 슈뤠귀"라는 소리를 듣는다. 그것이 바로 위의 함수에서 _MY_DEBUG라는 값을 따로 정의해서 사용하는 이유다.
인자로 넘긴 문자열을 Visual Studio 출력창에 찍어주는 OutputDebugString 함수를 쓰면 예전에 printf()로 하던 것처럼 디버깅할 수 있다. 특히 DebugView라는 프로그램을 실행하면 이 함수의 출력값을 -Visual Studio 출력창이 아닌- 윈도우 화면으로 확인할 수 있기 때문에 다른 사람의 컴퓨터에서 문제가 생겼을 때 아주 유용하다.
아래와 같이 함수를 하나 만들어 두면,
이렇게 사용할 수 있다. 단, 개발 완료 후 최종 사용자에게 배포할 때에는 이 OutputDebugString()이 호출되지 않도록 주의해야 한다. 너무나 당연한 것이, 입장을 바꾸어 내가 디버깅을 하려는데 DebugView 창에 듣도 보도 못한 프로그램이 이상한 메시지를 쏟아놓고 있으면 얼마나 짜증이 나겠는가 말이다. 국내의 한 상용 프로그램은 그 처리를 제대로 안 한 덕분에, 내가 아는 어떤 분으로부터 걸핏하면 "디버그 계의 슈뤠귀"라는 소리를 듣는다. 그것이 바로 위의 함수에서 _MY_DEBUG라는 값을 따로 정의해서 사용하는 이유다.
EscapeEnglish_0_1a.zip
