Link Copied
Dok:
Also as a note, from the KB article I supplied, it appears this issue occurs with any 3rd party DLL that you may use (not just MFC). Which makes it dangerous to do a global replace of the new and delete if using any 3rd party DLL's that exposes objects you can new and delete.
I think the problem is not that bad. The KB article you referenced is only relevant to really old MSVC versions (see the APPLIES TO list there) so I suppose modern versions should not have this issue. MFC, however, has a bug (as mentioned in one of the discussions I provided the links to) that it uses ::operator new to allocate objects, and free to deallocate. Here is the corresponding source code:
void* PASCAL CObject::operator new(size_t nSize)
{
#ifdef _AFX_NO_DEBUG_CRT
return ::operator new(nSize);
#else
return ::operator new(nSize, _AFX_CLIENT_BLOCK, NULL, 0);
#endif // _AFX_NO_DEBUG_CRT
}
void PASCAL CObject::operator delete(void* p)
{
#ifdef _AFX_NO_DEBUG_CRT
free(p);
#else
_free_dbg(p, _AFX_CLIENT_BLOCK);
#endif
}
For a 3rd party DLL exposing objects thatare allocated with global new and deallocated with global delete, and in the assumption thatcompiler-generated helper functions call operator delete properly as mandated by the standard, the problems may only arise if both the DLL and your application replace global new and delete. The standard explicitly says that "A C + + program shall provide at most one definition of a replaceable allocation or deallocation function. Any such function definition replaces the default version provided in the library". This is one of the reasons we do not provide replacement forms of new and delete with the TBB scalable allocator.
So if the 3rd party DLL does not provide its own replacement for global new and delete (which I think is a bad idea due to the restriction above), you should be fine using yours, assuming the compiler and linker do proper job of replacing the default operators with your version, as mandated by the standard.
