DEBUG_NEW : undeclared identifier

[Wesley T. Perkins]

Hello,

I have a recurring problem when developing software projects that involve
several different subprojects -- typically an application which uses one or
more utility classes which I have previously developed.

When trying to build the main program (debug configuration) there is an
error triggered in the compilation of one of the utility classes that reads:

error C2065: "DEBUG_NEW" : undeclared identifier

and things go downhill from there.

(I should say that I have not really mastered the art of configuring
projects, subprojects, dependencies, etc. so as to make everything go
smoothly all the time. In the present instance I have simply added the *.h
and *.cpp files for the utility class to the current project via
Project->Files->Add To Project->Files..)

Is there something simple (a setting?) that I can do to get past the
DEBUG_NEW problem?

Thanks,
Wesley

[Aaron Hughes]

Ok most of this is directly from the MSDN CD on DEBUG_NEW.
 

#define new DEBUG_NEW

Remarks

Assists in finding memory leaks. You can use DEBUG_NEW everywhere in your program that you would ordinarily use the new operator to allocate heap storage.

In debug mode (when the _DEBUG symbol is defined), DEBUG_NEW keeps track of the filename and line number for each object that it allocates. Then, when you use the CMemoryState::DumpAllObjectsSince member function, each object allocated with DEBUG_NEW is shown with the filename and line number where it was allocated.

To use DEBUG_NEW, insert the following directive into your source files:

#define new DEBUG_NEW

Once you insert this directive, the preprocessor will insert DEBUG_NEW wherever you use new, and MFC does the rest. When you compile a release version of your program, DEBUG_NEW resolves to a simple new operation, and the filename and line number information is not generated.

Note   In previous versions of MFC (4.1 and earlier) you needed to put the #define statement after all statements that called the IMPLEMENT_DYNCREATE or IMPLEMENT_SERIAL macros. This is no longer necessary.

If you are still getting an error, you may have other defines in other modules that are conflicting with DEBUG_NEW.
Since it appears you can only use this in debug mode you may have in one module

#ifndef _DEBUG
    #define _DEBUG
#endif

and in another module

#ifndef _RELEASE
    #define _RELEASE
#endif

So really what you are doing is telling the compiler to be in both debug mode and release mode.

Anyway I hope this helps.

[chiuyan]

His problem is that DEBUG_NEW is undefined, #defining the new operator is
not going to fix that (if he is building a debug version, then new is
already #defined to be DEBUG_NEW).

DEBUG_NEW is defined in afx.h, so I am betting that your utility class is
not including that somewhere (or including a file that does include it, like
afxwin.h).

If you cannot determine why or where, you can just search for the
#define new DEBUG_NEW
in your utility class and delete it and just use new (I would recommend the
first option though)

--michael

P.S. To Arron Hughes, I am probably the only guy out there still using an
old newsreader (a command-line based one on a unix box), but for those of us
who do reading news that is posted in HTML format (like your message was),
is a real pain. Posting in plain text would be preferrable (for me anyway
;-).
Aaron Hughes wrote in message <373CE07B...@kos.net>...

Ok most of this is directly from the MSDN CD on DEBUG_NEW.

#define new DEBUG_NEW

Wesley T. Perkins wrote:

[Roger H. Joerg]

Wesley T. Perkins wrote in message
<7hihns$40b$1...@nntp.gulfsouth.verio.net>...

>Hello,
>
>I have a recurring problem when developing software projects that involve
>several different subprojects -- typically an application which uses one or
>more utility classes which I have previously developed.
>
>When trying to build the main program (debug configuration) there is an
>error triggered in the compilation of one of the utility classes that
reads:
>
>error C2065: "DEBUG_NEW" : undeclared identifier
>
>and things go downhill from there.
>
>(I should say that I have not really mastered the art of configuring
>projects, subprojects, dependencies, etc. so as to make everything go
>smoothly all the time. In the present instance I have simply added the *.h
>and *.cpp files for the utility class to the current project via
>Project->Files->Add To Project->Files..)
>

Good approach to prevent from fumbling around with the project
settings. But you should make sure that the compiler defines
either _DEBUG or NDEBUG.
If the subproject doesn't change often, you could use the following
approach:

change your "stdafx.h" to include your subprojects .h file.
change your "stdafx.cpp" to include your subprojects .cpp file
remove the #include "stdafx.h" from your subprojects .cpp file

Regards, Roger