이 이야기가 왜 나왔냐 하면, 큰 문제를 놓치는 경우가 생길 수 있기 때문이다. 나의 경우 주로, 형변환이나, 사용되지 않은 변수, 함수의 인자를 사용하지 않는 경우, 리턴이 없는 경우가 제일 많았다.
이 중에서 경고를 무시하다가 직접 겪어 보았던 문제는 바로, "실수형에서 정수형으로 형 변환 하게 될 경우 값이 소실 되는 경우"를 들 수 있다. 예를 들어서, 아래 코드를 보자.
i는 값이 몇일 꺼라 생각 하는가? 이 처럼 실수형에서 정수형으로 바꿀 때는 .. 값이 소실 되어 버려, 의도하지 않은 값으로 리턴 되게 될 경우가 생긴다.
겪어 보면, "경고를 모두 없애버리겠어!" 라는 의지를 갖게 되니, 한번쯤 이런 경험을 해 보는 것도 나쁘지 않을 것이다. 이 책에서 이번 장에서 말하고자 하는 의미가 바로 이것이다.
경고를 무시하다가 정말 큰일 나는 수가 있기 때문이다.
이번 책에서 새롭게 안 사실은, "원래부터 경고를 발생하는 표준 헤더 파일의 경우, wrapper 헤더를 만들어서 포장하고, #pragma warning 기법으로 최소화 시키는 방법이다" 소스 코드를 보자.
여기서의 stack 이란 warning state 의 저장소이며, 저장 방식은 stack 을 따른다. warning state 란, warning 명령들을 적은 놓은 종이라 봐도 되겠다.
비유해서 말하자면, #pragma warning( push )는 현재의 warning 명령서 위에 새로운 warning 명령서를 올려 놓는다. 그리고 거기에 새로운 명령(#pragma warning( disable:4512 ) 등 )을 써 넣을 수 있다.다. 마지막으로 #pragma warning( pop )은 맨 위에 있는 warning 명령서를 버리는 것이다. 아참, 기존의 명령들도 유효하지만, 새로운 명령에 더 우선권을 둔다.
본론으로 돌아와서, 이 기법은, warpper 헤더에 경고가 나는 헤더파일을 이렇게 포함시킴으로써, 경고를 없애고, 다른 곳에서의 경고는 발생 시켜, 경고의 발생 위치를 보다 편하게 찾기 위한 것이다.
총평
warning 에 대해서는 http://msdn.microsoft.com/en-us/library/2c8f766e(VS.80).aspx 참조 하는게 좋을 것 같다. 내가 이해한 warning 과 다를 수 있으니 말이다.
'책 정리 > C++ Coding Standards : C++ 코딩의 정석' 카테고리의 다른 글
항목 9 : 미리 최적화해두어야 할 부분도 있다. ( Don’t pessimize prematurely. ) (0) | 2009.02.11 |
---|---|
항목 8 : 이른 최적화를 피하라. ( Don’t optimize prematurely. ) (0) | 2009.02.11 |
항목 7 : 적절한 규모 유지를 위해서는 '언제, 어떻게'를 아는 것이 중요하다. ( Know when and how to code for scalability. ) (0) | 2009.02.11 |
항목 6 : 정확성, 간결성, 명확성을 먼저 생각하라. ( Correctness, simplicity, and clarity come first. ) (0) | 2009.02.06 |
항목 5 : 하나의 엔티티에는 하나의 역활만을 부여하자. ( Give one entity one cohesive responsibility. ) (0) | 2009.02.06 |
항목 4 : 코드 리뷰에 시간을 투자하라 ( Invest in code reviews ) (3) | 2009.02.03 |
항목 3 : 버전 컨트롤 시스템을 사용하라 ( Use a version control system ) (0) | 2009.02.03 |
항목 2 : 자동화된 빌드 시스템을 사용 하라 ( Use an automated build system ) (0) | 2009.02.03 |
항목 0 : 작은 것에 연연하지 말라. ( Don’t sweat the small stuff. ) (0) | 2009.02.03 |
C++ 코딩의 정석 : C++ Coding Standards 오늘 구입했다. (0) | 2009.02.02 |
최근댓글