Re: Some compatibility issues using STL.
See the code snippet below.
This code worked fine under VC6 and VC7, but results in heap corruption
FileName is a utility class that stores the drive, path, name and ext of
a filename which allows for easy and safe modification of either these
parts (using std::string as the storage container). WINUTILITY_EXPORT is
defined as _declspec(dllexport) i the DLL project and as
_declspec(dllimport) for all users of the DLL.
The code is in a DLL and called from other DLLs and an executable.
Are you compiling everything to use the same version of the DLL-based
CRT (under Code Generation settings)? If not, then heap corruption is
expected if you allocate memory in one DLL/EXE and free it elsewhere.
In VC8 I noticed that as soon as I assigned buf to fn, the debugger
displays bad_ptr for all FileName members when called from my
executable. This is also the case when I return fn by copy instead of by
What happens when you trace into the assignment "fn = buf;"?
I gathered that VC8 changed some thing regarding STL and STL exports.
The secure SL stuff was added, but that doesn't cause any problems as
long as everything uses the same settings. I assume you've recompiled
everything under VC8?
How can I get around this?
What DLL is FileName part of? What does it look like? Probably all you
need to do is set all your DLLs to use the same heap (/MD or /MDd I
think), and are all compiled with VC8, and all use #define _SECURE_SCL 0
or #define _SECURE_SCL 1, and the problem may go away. Otherwise it may
be a problem with FileName itself. Incidentally, I'd rewrite your
WINUTILITY_EXPORT const FileName& GetAppName()
static FileName fn;
if( fn.IsEmpty() )
GetModuleFileName( 0, &buf, MAX_PATH );
fn = buf;
Also, note that the function isn't thread-safe, so you may want to put a
critical section in there.