Using both STL and MFC with Visual C++ 5.0 
Author Message
 Using both STL and MFC with Visual C++ 5.0

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.



Mon, 16 Apr 2001 03:00:00 GMT  
 Using both STL and MFC with Visual C++ 5.0
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.

Quote:

>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:



Mon, 16 Apr 2001 03:00:00 GMT  
 Using both STL and MFC with Visual C++ 5.0


Fri, 19 Jun 1992 00:00:00 GMT  
 Using both STL and MFC with Visual C++ 5.0

Quote:

>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.

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.



Tue, 17 Apr 2001 03:00:00 GMT  
 Using both STL and MFC with Visual C++ 5.0
[Cut stuff re conflict between MFC's afx.h and STL headers.]
Quote:
>> I solved that problem with a pair of files used thusly:

[Cut new_unhack.h and new_rehack.h ]

Quote:
>Although I'd agree that the use of #define is not a good solution for what
>MFC is trying to do here, your solution is not needed. The only reason
>you're having problems is because you're putting your #include statements in
>the wrong position.

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.

Quote:
>#include <afxres.h>  // example of MFC header
>#include <string>    // STD headers should also be in this block!!

>// MFC debug new technique
>#ifdef _DEBUG
>#define new DEBUG_NEW
>#undef THIS_FILE
>static char THIS_FILE[] = __FILE__;
>#endif

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.

Quote:
>#include <list>     // Must NOT include headers after the #define new!!!

>In the above example, #include <list> will give you the grieve you're
>complaining about, while #include <string> will not.  If you really are sick
>of all of this, you can always just delete the #define new stuff, as it's
>sole purpose is to provide you with debugging facilities for detecting memroy
>leaks. It won't hurt the code any at all to remove this, it just means
>you'll need some other method to detect memory leaks.

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.



Wed, 18 Apr 2001 03:00:00 GMT  
 Using both STL and MFC with Visual C++ 5.0
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

Quote:

>...
>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.



Fri, 27 Apr 2001 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Using both STL and MFC with Visual C++ 5.0

2. Using both STL and MFC in Visual C++ 5.0

3. Using both STL and MFC with Visual C++ 5.0

4. Converting MFC Visual C++ 2.0 application to MFC Visual C++ 5.0

5. Combining STL and MFC in Visual C++ 5.0

6. More STL in Visual C++ 5.0 MFC Applications

7. Help: Using Borland C++ 16 bit DLL with Visual C++ 5.0

8. Visual C++ 5.0 STL error

9. Visual Basic 5.0 vs. Visual C++ 5.0

10. Visual Basic 5.0 vs. Visual C++ 5.0

11. Visual Basic 5.0 vs. Visual C++ 5.0

12. MS Visual C++ 5.0 or Borland C++ 5.0?

 

 
Powered by phpBB® Forum Software