THIS_FILE' : redefinition; different storage class while changing setting from /MD to /MDD
in [MFC]
|
Prev: THIS_FILE' : redefinition; different storage class while changing setting from /MD to /MDD
Next: _in s and _out s ?
From: Joseph M. Newcomer on 28 Apr 2010 18:32 I have no idea why MFC would put an #undef in, unless some earlier version had defined THIS_FILE as a macro. But given the poor quality of information we were given about the problem (it didn't even say which file issued the error message! Or which file had the code!) it is hard to play psychic detective and guess what is going on. joe On Wed, 28 Apr 2010 06:34:08 -0700 (PDT), Steve Achelis <info(a)RescueRigger.com> wrote: >On Apr 28, 1:20�am, Girish <giris...(a)gmail.com> wrote: >> Hi, >> I �working in finding out the memory leak in the application which was >> developed in vc++2005. I am using �_CrtMemCheckpoint function to �find >> out the memory leak these function will be working only when the >> application is in debug mode and the project setting should in /MDD >> or /MTD . >> When ever I change my setting from /MD to /MDD I get a compiler error >> Error � � �251 � � � � error C2370: 'THIS_FILE' : redefinition; >> different storage class >> i.e � error is at >> #ifdef _DEBUG >> #define new DEBUG_NEW >> #undef THIS_FILE >> #pragma once >> static char THIS_FILE[] = __FILE__; >> #endif >> >> When I try to remove this and build I can build the application but it >> crashes . >> Could you please help me out what is changes �I need to make to run >> the application successfully. >> >> Thanks in Advance, >> Regards, >> Girish > >Girish, for what it's worth, all of my cpp files (created by earlier >versions of MFC), have this code near the top (and compiles fine with >debug or release builds): > >#ifdef _DEBUG >#define new DEBUG_NEW > >#undef THIS_FILE >static char THIS_FILE[] = __FILE__; >#endif > >Not the pragma you showed. And so to Joe, the undef THIS_FILE was put >there by MFC... > >As to finding your memory leak, I sometimes resort to the caveman-like >approach of removing blocks of code. I save a copy of my source code >(the entire folder), delete a big chunk of code (that will still allow >my app to run), see if it still leaks, and repeat until I can narrow >down what is causing the leak. This approach isn't guaranteed to >isolate the problem, but it usually works for me. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Oliver Regenfelder on 30 Apr 2010 05:45
Hello, Girish wrote: > Hi All, > First I need to say thanks for every one for proving your ideas. > I got the solution for the problem which i was facing. > by setting the below variables to 0 > > #define _HAS_ITERATOR_DEBUGGING 0 > #define _SECURE_SCL 0 > > after define this we can remove the below code and build the > application with out any error or any crash. > > #ifdef _DEBUG > #define new DEBUG_NEW > #undef THIS_FILE > #pragma once > static char THIS_FILE[] = __FILE__; > #endif So you solved it by removing certain debug and error checks!? Best regards, Oliver |