ifstream in mfc cause strange errors in debug only [modified]

FredrickNorge

I use vs2005, when i want to debug my mfc app with #include fstream i get a endless list of problems refering to the xdebug(32)file. A few errors: 1>C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\xdebug(32) : warning C4229: anachronism used : modifiers on data are ignored 1>C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\xdebug(32) : error C2365: 'operator new' : redefinition; previous definition was 'function' 1>C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\xdebug(32) : error C2078: too many initializers 1>C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\xdebug(32) : error C2440: 'initializing' : cannot convert from 'int' to 'void *' When i do a release however, everything works just fine... any sugestions? - Fred -- modified at 12:26 Tuesday 18th July, 2006

Maxwell Chen

The order of #include's may matter. Which do you include first? "stdafx.h" or <fstream> ?

Maxwell Chen

FredrickNorge

stdafx.h is before fstream

toxcct

i don't think it is the matter here, otherwise he would have got a "precompiled header"-like error

TOXCCT >>> GEII power

[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]

Cedric Moonen

As the problem is only in debug mode, maybe there is something wrong with some preprocessor definition. If you have a #ifdef _DEBUG statement at the top of your file, post it here (completely) so we can have a look.

Cédric Moonen Software developer
Charting control

FredrickNorge

ok, ive tried without the #ifdef _DEBUG #include "stdafx.h" #include "resource.h" #include "Dialog1.h" #include "Dialog2.h" #include "assert.h" #include #include "Dialog3.h" #include #include /* Needed only for _O_RDWR definition */ #include #include #include "EmbeddedDialogDlg.h" #include "QuickMissLoadWriteEdit.h" #include #include "string.h" #include #include using namespace std; #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif code comes here

Cedric Moonen

Mmmh, I don't see really the problem here. Anyway, you are mixing deprecated header files with new ones. Remove all the include with a .h for the stadard library (stdio,io,string). I don't think this will solve the problem but check that first.

Cédric Moonen Software developer
Charting control

FredrickNorge

ok, thanks anyway :)

Maxwell Chen

FredrickNorge wrote:

vs2005, when i want to debug my mfc app with #include fstream

FredrickNorge wrote:

1>C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\xdebug(32)

Generally speaking, in a MFC/VS2005 project of Debug configuration, the version of operator new being invoked is: "afxmem.cpp" line 59,

void* __cdecl operator new(size_t nSize, LPCSTR lpszFileName, int nLine)
{
return ::operator new(nSize, _NORMAL_BLOCK, lpszFileName, nLine);
}

And then "afxmem.cpp" line 393,

void* __cdecl operator new(size_t nSize, int nType, LPCSTR lpszFileName, int nLine)
{
#ifdef _AFX_NO_DEBUG_CRT
UNUSED_ALWAYS(nType);
UNUSED_ALWAYS(lpszFileName);
UNUSED_ALWAYS(nLine);
return ::operator new(nSize);
#else
void* pResult;
#ifdef _AFXDLL
_PNH pfnNewHandler = _pfnUninitialized;
#endif
for (;;)
{
pResult = _malloc_dbg(nSize, nType, lpszFileName, nLine);
if (pResult != NULL)
return pResult;

#ifdef _AFXDLL
if (pfnNewHandler == _pfnUninitialized)
{
AFX_MODULE_THREAD_STATE* pState = AfxGetModuleThreadState();
pfnNewHandler = pState->m_pfnNewHandler;
}
if (pfnNewHandler == NULL || (*pfnNewHandler)(nSize) == 0)
break;
#else
if (_afxNewHandler == NULL || (*_afxNewHandler)(nSize) == 0)
break;
#endif
}
return pResult;
#endif
}

Maxwell Chen -- modified at 14:01 Tuesday 18th July, 2006

FredrickNorge

ok i tried to overide the calls, no luck :( . What ive done for now though, is commented the verry brief code that actualy use fstream when i debug, and uncomment it for the final release. Works ok for now...

Maxwell Chen

For this kind of problem, sometimes looking at the compilation log message may help. For example when you have such compilation output message as below:

Compiling ...
stdafx.cpp
test1.cpp
test2.cpp
test3.cpp
e:\wrkshp\test3.cpp(102) : error Cxxxx: blah blah blah
test4.cpp
test5.cpp
Test - 1 error(s), 0 warning(s)

Then you may try to back trace those existing definitions by looking at the included headers (and the related compilation units) in the last compilation (eg: test3.cpp) unit wherein errors are found.

Maxwell Chen

David Crow

FredrickNorge wrote:

#include <assert.h> #include <Windows.h> #include <io.h> #include <fcntl.h> /* Needed only for _O_RDWR definition */ #include <share.h> #include <stdio.h> #include <iostream> #include <string.h> #include <string> #include <fstream>

Why don't you have these in the stdafx.h file?

"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank

"Judge not by the eye but by the heart." - Native American Proverb

FredrickNorge

will do, thanks for all the inputt Maxwell Chen ;)