Discussion:
THIS_FILE' : redefinition; different storage class while changing setting from /MD to /MDD
(too old to reply)
Girish
2010-04-28 07:20:14 UTC
Permalink
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
Goran
2010-04-28 09:53:58 UTC
Permalink
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
We3ll, compiler is telling you that somehow you defined THIS_FILE more
than once. Without seeing all of the code you have, nobody can tell
where exactly is the problem. Is it possible that you put these macros
in a header file?
When I try to remove this and build I can build the application but it
crashes .
You have to tell people here what "crashes" mean more specifically.
You can gather much, much more info on "crashes". Where exactly is the
crash, in your sources? What is the crash? OS exception (e.g. access
violation) etc. How does your stack look like when crash occurs? Etc.

Don't be helpless. Look harder.

Goran.
Tom Serface
2010-04-28 11:31:09 UTC
Permalink
Could you have this in more than one .h file where one is included in
another so there really are two definitions?

Tom
Post by Girish
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
Joseph M. Newcomer
2010-04-28 13:10:36 UTC
Permalink
#undef does NOT undefine a symbol such as THIS_FILE; it can only undefine a symbol which
has been created by #define! So I have no idea what you are expecting the undef to do.

If you had another definition of THIS_FILE somewhere, this second definition is in
conflict with it, and the #undef is just silly noise.

I have no idea why you would put a #pragma once in a .cpp file! This is appropriate only
in header files, and it would NOT be conditioned under an #ifdef _DEBUG! So I have no
idea what the intent of the code below might be, except that it is completely wrong in so
many ways I'm not surprised it gives errors.

Of course, the #pragma once might be because this code was placed in a header file, in
which case it is clearly wrong in yet a new way: it is defining a variable (THIS_FILE)
which has the WRONG file name (the name of the header file) and which will be included as
a static variable in every module of your code.

Also, when you quote error messages, it is useful to quote the entire message, which
includes the file name. If you want to disguise the file name for proprietary reasons,
then replace the name (e.g., productname.h) with XXXXXXXX.h. But since you chose to hide
the filename, I'm having to guess at what you did wrong.

Fix the nonsense code below, remove the #undef, put it in a .cpp file, and if the problem
is that the code is in your .h file, move the code to a .cpp file where it belongs.
joe
Post by Girish
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
Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Steve Achelis
2010-04-28 13:34:08 UTC
Permalink
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.
Tom Serface
2010-04-28 13:45:57 UTC
Permalink
This article may also be useful to OP:

http://www.codeproject.com/kb/cpp/MemLeakDetect.aspx

I've, like you, often resort to the brute force method, just using Task
Manager and looking for blocks in the debug build that show up at the end of
the run in the Output window and things like that...

Tom
Post by Steve Achelis
Post by Girish
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
#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
2010-04-28 22:32:52 UTC
Permalink
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
Post by Steve Achelis
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
#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: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Girish
2010-04-30 07:12:50 UTC
Permalink
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


Regards,
Girish
Post by Joseph M. Newcomer
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
Post by Steve Achelis
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
#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]
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm
Oliver Regenfelder
2010-04-30 09:45:20 UTC
Permalink
Hello,
Post by Girish
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
Joseph M. Newcomer
2010-04-30 16:36:11 UTC
Permalink
See below...
Post by Oliver Regenfelder
Hello,
Post by Girish
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!?
****
In an (in)famous incident, the story goes, a torpedo was made "safe" by the following
technique:

One on the serious dangers to a submarine is having its own torpedo loop back and acquire
its sending submarine as a target. So a "safe" torpedo was created that had an inertial
platform, and if the torpedo every executed a 180-degree turn it would detonate.

During the testing, a torpedo with a small dummy warhead was taken out on trial. Due to
some mechanical failure in the torpedo tube, the torpedo jammed in the tube. After
several attempts to dislodge it, the submarine turned to head back to port.

Also, while the torpedo had not launched, its safety systems were activated. The torpedo
did as it was supposed to, and exploded.

Because the warhead was a small dummy load, it did not destroy the submarine, but caused
several million dollars in damage.

This taught the torpedo designers a lesson. The next torpedo had a LOT of safety software
in it. They took it out on trial. They fired it. As soon as it left the tube, all the
safety software enabled (no detonation in the tube) but what happened was the motor then
stopped and torpedo sank to the bottom of the ocean.

Moral: removing safety code is bad; putting in too much is worse.

Unfortunately, the way this was solved was simply by removing more and more safety code
until the torpedo actually appeared to work. Very little effort was expended in
determining if the safety code that was removed compromised ACTUAL safety. Sort of a
hack-and-try approach was used. It was then that some of the world's experits in software
safety were called in to do a review of the software. They were appalled at what they
found, but because of National Security Considerations can neither disclose what they
found nor discuss what they did to correct it. So the story above is pretty much all they
can give (I learned this from one of the software safety experts, at a conference on
software safety)

Does anyone remember "Diamond" brand graphics cards? A few of us had them, but Diamond,
to make performance goals, got rid of a lot of code that contributed nothing to the
performance, such as bounds checking, parameter validation, etc., This is approximately
the phone call I had with them:

"...and every time I zoom into a slide in PowerPoint, Windows bluescreens"

"Well sir, do you have the latest build of the driver?"

"Yes, I downloaded it today."

"What timestmp does it have?"

<<Pause while I bring up the file manager and look at the timestamp>>

"[A little after 10am] today"

"Then you don't have the latest build. You need the 2pm release"

Shortly after that, I went out and bought a different brand of card. Diamond Video
shortly thereafter went out of business, because no one EVER bought a second card from
them, and those who paid attention to the newsgroups in which it was discussed never
bought a first card from them (lucky users!)

You need really good reasons for disabling safety code. Only if your torpedo sinks
immediately after launch is this justified. And then, it must be done with care. It is
more important to find out why you are getting failures than to just disable the safety
code and hope nothing goes wrong.
****
Post by Oliver Regenfelder
Best regards,
Oliver
Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
David Ching
2010-04-30 22:48:39 UTC
Permalink
Post by Joseph M. Newcomer
Does anyone remember "Diamond" brand graphics cards? A few of us had them, but Diamond,
to make performance goals, got rid of a lot of code that contributed nothing to the
performance, such as bounds checking, parameter validation, etc., This is approximately
That is funny. I also lost money on them when I bought the Diamond Viper
which was the fastest card for Windows 3.1, but due to 'architectural
limitations' they could not deliver a Win 95 driver in 3 attempts.

-- David

Hector Santos
2010-04-28 17:38:12 UTC
Permalink
Why do you have the

#pragma once?

Just use this:

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

I just checked something. If you have to use CrtMemCheckpoint, then
you are not MFC ready.

I have a lot of test and design code that are console only, where I
will isolate a new class and do rapid development and testing under my
programmer editor.

To use the crtdbg.h, here is an example test code using this crtdbg
facility:

---------------------- CUT HERE --------------------------
// File: testurl.cpp
//
// cl testurl.cpp /W3 /EHsc /MDd /D /Zi /Od /D "WINVER=0x500"
// /D "WIN32" /D "_DEBUG" /D "_WINDOWS"
// /FR /link /debug
//

#include <stdio.h>
#include <windows.h>

#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#endif

#include "url.cpp" // new URL parser

void ParseUrl(const char *str)
{
URL *url = urlparse(str);
printf("- %4s URL: %s\n", url?"GOOD":"BAD", str);
if (url) urlfree(url);
}

void main(char argc, char *argv[])
{
#ifdef _DEBUG
_CrtMemState memstate1;
_CrtMemState memstate2, memdiff;

// Send all reports to STDOUT
_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT );
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDOUT );
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDOUT );

_CrtMemCheckpoint(&memstate1);
#endif

ParseUrl("/public/test1.php?title=special:123");
ParseUrl("/public/test1.php?title=special/page_name");
ParseUrl("/public/test1.php?title=special:123/page_name");
ParseUrl("/public/test1.php?/title=special:123/page_name");

#ifdef _DEBUG
_CrtMemCheckpoint(&memstate2);
if ( _CrtMemDifference( &memdiff, &memstate1, &memstate2 )) {
printf("***** MEM LEAK *******\n");
_CrtMemDumpStatistics( &memdiff);
_CrtMemDumpAllObjectsSince(&memdiff);
_CrtDumpMemoryLeaks();
}
#endif
}
---------------------- CUT HERE --------------------------
Post by Girish
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
--
HLS
Girish
2010-04-30 07:18:55 UTC
Permalink
While changing the project setting from /md to /mdd or /mt to /mtd we
should make sure that all the dependency dll and modules are in the
same form i.e in debug mode if not then we would be facing this type
of problem .
in this case we could not use some of debugging functions like
_CrtMemCheckpoint to use this type function we need to define
#define _HAS_ITERATOR_DEBUGGING 0
#define _SECURE_SCL 0

which could give some ASSERT msg which would not crash be an issue.

Regards,
Girish
Post by Hector Santos
Why do you have the
      #pragma once?
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
I just checked something. If you have to use CrtMemCheckpoint, then
you are not MFC ready.
I have a lot of test and design code that are console only, where I
will isolate a new class and do rapid development and testing under my
programmer editor.
To use the crtdbg.h, here is an example test code using this crtdbg
---------------------- CUT HERE --------------------------
// File: testurl.cpp
//
// cl testurl.cpp  /W3 /EHsc /MDd /D /Zi /Od /D "WINVER=0x500"
//                 /D "WIN32" /D "_DEBUG" /D "_WINDOWS"
//                 /FR /link /debug
//
#include <stdio.h>
#include <windows.h>
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#endif
#include "url.cpp" // new URL parser
void ParseUrl(const char *str)
{
    URL *url = urlparse(str);
    printf("- %4s URL: %s\n", url?"GOOD":"BAD", str);
    if (url) urlfree(url);
}
void main(char argc, char *argv[])
{
#ifdef _DEBUG
    _CrtMemState memstate1;
    _CrtMemState memstate2, memdiff;
    // Send all reports to STDOUT
    _CrtSetReportMode( _CRT_WARN,    _CRTDBG_MODE_FILE );
    _CrtSetReportFile( _CRT_WARN,    _CRTDBG_FILE_STDOUT );
    _CrtSetReportMode( _CRT_ERROR,   _CRTDBG_MODE_FILE );
    _CrtSetReportFile( _CRT_ERROR,   _CRTDBG_FILE_STDOUT );
    _CrtSetReportMode( _CRT_ASSERT,  _CRTDBG_MODE_FILE );
    _CrtSetReportFile( _CRT_ASSERT,  _CRTDBG_FILE_STDOUT );
    _CrtMemCheckpoint(&memstate1);
#endif
    ParseUrl("/public/test1.php?title=special:123");
    ParseUrl("/public/test1.php?title=special/page_name");
    ParseUrl("/public/test1.php?title=special:123/page_name");
    ParseUrl("/public/test1.php?/title=special:123/page_name");
#ifdef _DEBUG
    _CrtMemCheckpoint(&memstate2);
    if ( _CrtMemDifference( &memdiff, &memstate1, &memstate2 )) {
       printf("***** MEM LEAK *******\n");
       _CrtMemDumpStatistics( &memdiff);
       _CrtMemDumpAllObjectsSince(&memdiff);
       _CrtDumpMemoryLeaks();
    }
#endif}
---------------------- CUT HERE --------------------------
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
--
HLS
Continue reading on narkive:
Loading...