I am currently adding some new functionality to an existing MFC
application. The implementation of the new functionality depends heavily
on STL. Now when I try to compile the application I get the following
error:

{Visual C++ include path}\new(44) : error C2373: 'set_new_handler' :
redefinition; different type modifiers

The error only surfaces when I include the STL specific header files,
which I definately need.

If I define _NEW_ before I include the STL header files the application
compiles in Release mode and it even seems to behave "properly".
However, if I compile the application in Debug mode, I get the following
errors:

{Visual C++ include path}\new(31) : error C2061: syntax error :
identifier 'THIS_FILE'
{Visual C++ include path}\new(31) : error C2091: function returns
function
{Visual C++ include path}\new(31) : error C2809: 'operator new' has no
formal parameters
{Visual C++ include path}\new(32) : error C2061: syntax error :
identifier 'THIS_FILE'
...

So, is there a way to use STL with MFC without these errors ? I have
used STL often with Visual C++ 5.0 and every time without a problem, it
is just the combination with MFC that gives me these troubles.

With kind regards,

Pieter Swinkels.

I think you need to insure that STL headers come before the crappy

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

stuff that MFC puts into each .cpp file for memory leak detection.

I solved that problem with a pair of files used thusly:

#include <afx.h>
/// ...

#include <SysFix/new_unhack.h>
#include <string>
/// (or other STL headers that may get to use of placement new)
#include <SysFix/new_rehack.h>

These files are pretty simple:
===================================================
// new_unhack.h

// HACK ALERT!!!  To overcome an idiotic #define of the keyword new,
// this adjustment is made.  The "correct" solution to this problem
// is to find a way to not #define new in the first place, but that
// requires delving into MFC-idiocy more deeply than sanity can bear.
#if defined(new)
  #ifdef DEBUG_NEW
    #undef REDEFINE_NEW_HACK
    #define REDEFINE_NEW_HACK
    #undef new
  #else
    #error "MFC's hacked new is strangely different."
  #endif
#endif

// Include this at any time, (even multiply), to neutralize MFC's
// new hack so that the keyword can be used as specified by C++.
// Includers of this file normally include new_rehack.h afterward.
===================================================
// new_rehack.h

//  HACK ALERT!!!  See new_unhack.h for an explanation.
#ifdef REDEFINE_NEW_HACK
  #ifdef DEBUG_NEW
    // Blindly hoping this undoes earlier #undef ...
    #define new DEBUG_NEW
    #undef REDEFINE_NEW_HACK
  #else
    #error "MFC's hacked new is strangely different."
  #endif
#endif

// Includers of this file normally include new_unhack.h earlier.
// Include this at any time, (even multiply), to reinstate MFC's
// new hack in case it was undone via #include <new_unhack.h>
===================================================

This is not as robust a solution as I would like, being
sensitive to exactly how MFC has butchered the
keyword "new".  But it at least localizes the fixup
assumption to one place that can be repaired at
such time as team-MFC finds a saner way to do
their allocation instrumentation.

--Larry Brasfield
Above opinions may be mine alone.

[Cut stuff re conflict between MFC's afx.h and STL headers.]
[Cut new_unhack.h and new_rehack.h ]

I have to disagree here.  While investigating the problem, I
also discovered that reordering includes would "cure" it.
After considering that alternative, I chose my solution
because I wanted the MFC headers in a .PCH and was
unwilling to stuff every possible STL include into the same
.PCH just to cater to a hack that I consider bone-headed.

You might say the only reason I was having problems is
that I am too stubborn to let some little hack dictate how
common includes, PCH use, and subsequent includes
are going to be structured for my (our) whole project.  I
cannot duck that charge.  I admit it.  My stubbornness
reflects what I view as a sound design principle, which
is to not allow solutions of little issues to leak out into a
realm where solutions of larger problems are impacted.
My solution contains the problem instead of distorting
how we solve what should be unrelated problems.

The problem is that the above hack is in afx.h .
Either afx.h gets left out of the precompiled
headers, or a bunch of STL files not usually
used have to go into the .PCH.  Just to make
that a more interesting choice, the VC6
compiler starts croaking with complaints
about heap space and need for /Zm switch
when some of our larger (auto-generated)
files get compiled with MFC, most of STL,
and the truly common project headers.  The
STL adds a lot to the .PCH's.

I am really sick of keywords being #define'd.  Someday,
possible in another lifetime, I will use an alternative
dynamic memory checking facility.

--Larry Brasfield
Above opinions may be mine alone.

The memory leak reporting provides the source file and line number of the
allocation that wasn't freed. (On the theory that you might like to correct
the problem it reported. :-))

To be able to do so, the debug version of operator has extra arguments, so
that _FILE_ and _LINE_ can be passed to it.

Thus there's a macro to make this call with the extra args automatically and
transparently, in _DEBUG builds.

That's the rationale for a #define. Although I haven't tried hard, I can't
think of an alternative. Maybe something utilizing the de{*filter*} source info
from the PDB? Would that have limitations, e.g. for LIBs that don't share a
PDB?

--
Greg