티스토리 뷰
[MFC] #define new DEBUG_NEW와 static char THIS_FILE[] = __FILE__;
jhbaek 2011. 2. 11. 10:01MFC에서 보면 아래와 같은 소스 코드가 있다.
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif // _DEBUG
이것에 대해 엄청난 궁금증이 있었지만 그려러니 하고 넘어갔었다.
그러던 중 우연치않게 이 용도를 알았다.
프로그래밍하던중 종료시에 "Detected memory leaks!" 이란 메시지를 우연찮게 발견했다.
아무래도 어디선가 new를 했다 delete 를 하지 못해 구천에서 떠도는 원혼의 소리 같은 필이팍! -_-;
하지만 어디서 나오는지 도저히 알 방법이 없었다.
힌트라도 주면 디버깅을 하겠지만 이건 뭐... 완존히... -_-;;
그래서 나름대로 사이트를 뒤적거리던중 ms 사이트에서 이걸 발견했다.
cpp 파일에다가 이걸 선언하면 (h에 하면 않된다.) 해결이 된다.
그렇다면 한번 예를 적겠다. 생성자에 아래와 같은 코드를 넣는다.
char *p = new char[4444];
물론 고의 적으로 delete p; 를 하지 않는다.
#define new DEBUG_NEW를 cpp 꼭대기에 선언하지 않았을 경우 디버그 모드로 실행하다
종료하면 디버깅창에 아래와 같은 메시지가 나온다. 몇번지에 몇 바이트까지 나온다.
원혼이 떠도는지는 알겠지만 원인은 모른다. ㅠㅠ
Detected memory leaks!
Dumping objects ->
{71} normal block at 0x00E1B748, 4444 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
#define new DEBUG_NEW를 해당 cpp 꼭대기에 선언한 경우는 종료시 아래와 같이 나온다.
Detected memory leaks!
Dumping objects ->
C:\어쩌고저쩌고\Test.cpp(172) : {71} normal block at 0x00E1B748, 4444 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
아! 얼마나 훌륭한가?
만약 선언되지 않은 cpp에 메모리 릭이 발생된다면 위치는 가르쳐 주지 않을것이다.
이제 원인을 아니까 성불 시킬수 있을것이다! (일본만화를 너무 많이 봤나? -_-)
모든 클래스의 사이즈를 외운다면 필요없겠지만.. 못외우는 분은 알고 있으면 좋을것 같다. ^^
이런 삽질을 반복하고 나서 이 코드의 의미를 알게 되었다.
이 덕분에 리소스 관리자의 버그를 찾아내었다. ^^;;
바꿔 말하면 버그 있는지 모르고 게임이 나올뻔했다. -_-;
ps... 이것은 어디까지나 MFC에 한해서 작동된다. 따라서
#ifdef _AFXDLL
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif // _DEBUG
#endif // _AFXDLL
라고 쓰는 것이 좋을 것이다.
참고한 곳 은 모두 현재 존재 하지 않는 url 이다.
또한 Visual Studio 버전에 따라 표현이 바뀌었을수도 있다.
윗 글은 http://balrog.tistory.com/5 에서 퍼왔음.
#undef THIS_FILE
기존에 THIS_FILE이 정의 되었을시 다시 재 정의 하겠다는 뜻입니다.
__FILE__은 ANSI가 정의한 미리 정의된 매크로로서 현재 소스 파일의 이름과 행 번호를
의미하는 매크로 입니다.
ex) 1.cpp라는 소스파일로 저장했을시
printf(""%s\n",__FILE__);
하면 결과는
%PATH%1.cpp라는 결과를 얻게 됩니다.
__FILE__ 는 이러한 특성상 디버그용으로 많이 쓰입니다.
하지만, 문제점이 있는데 __FILE__경우 a.cpp b.cpp
중 a.cpp가 #include b.cpp했을 경우 매크로의 확장 후에 컴파일 되기 때문에
__FILE__이 있을 경우 결과값이 b.cpp가 아닌 a.cpp를 나타내는 오류를 범하게 됩니다.
결국 이러한 현상을 막기위해 static 동적 char THIS_FILE[]=__FILE__; 로 만들어 이러한
오류가 나지 않게 합니다.
MFC를 사용할경우 자동으로 생성한 각 cpp파일에 디버깅 모드의 정적 변수로 THIS_FILE이 정의 되어 있기 때문에 별로 신경 안쓰셔도 될겄 같습니다.
윗 글은
http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=1040101&docId=66632327&qb=c3RhdGljIGNoYXIgVEhJU19GSUxFW10gPSBfX0ZJTEVfXzs=&enc=utf8§ion=kin&rank=1&search_sort=0&spq=0&pid=gSf5Mv331zZsssphLvVssv--080252&sid=TVSEpm5vVE0AAApVE8k
에서 퍼왔음.
'Development > Windows' 카테고리의 다른 글
[Visual C++] MultiByteToWideChar와 WidecharToMultiByte의 사용. (0) | 2011.05.12 |
---|---|
[Visual C++] shift_jis 인코딩 문제 (0) | 2011.05.11 |
[MFC] ScrollBar 사용하기 (4) | 2011.02.18 |
[MFC] Slider Control 사용법 (0) | 2011.02.18 |
[MFC] MESSAGE MAP (0) | 2010.12.14 |
[MFC] Error: The Extender Provider failed to return an Extender for this object (0) | 2010.12.08 |
[MFC] 브레이크 포인트가 저절로 해제될 경우 (0) | 2010.12.07 |
[MFC] class의 헤더에서 멤버 클래스 변수 포인터를 사용할 때 (0) | 2010.12.06 |
- Total
- Today
- Yesterday
- it
- linux
- database
- NDK
- 드라이버
- 음악
- java
- C++
- 안드로이드
- Cloud
- winapi
- API
- Python
- AWS
- Visual C++
- Quiz
- jni
- 프로그래밍
- android
- db
- MFC
- algorithm
- gcc
- Troubleshooting
- C
- 리눅스
- source
- jni강좌
- driver
- kering
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |