If you happen to use MSVC 4.0 with its MFC, you will get this little present
as the operator new:
- ----- from afxmem.cpp -----------------------------------
void* __cdecl operator new(size_t nSize)
{
    void* pResult;
    AFX_MODULE_THREAD_STATE* pState = AfxGetModuleThreadState();
    _PNH pfnNewHandler = pState->m_pfnNewHandler;
    do
    {
#if !defined(_AFX_NO_DEBUG_CRT) && defined(_DEBUG)
        pResult = _malloc_dbg(nSize, _NORMAL_BLOCK, NULL, 0);
#else
        pResult = malloc(nSize);
#endif
    } while (pResult == NULL && pfnNewHandler != NULL &&
(*pfnNewHandler)(nSize) != 0);
    return pResult;
}
- ------------------------------------------------
Do you see what happens here? It calls AfxGetModuleThreadState, a quite
complex function that will lock a module-wide critical section, fecth a value
from the thread-local storage, scan a list, etc. And all for what?
Did anyone of you ever changed the new handler? And at all, why bother with
the new-handler when 99.99% of the time allocation will be successful.
If you use this version I strongly suggest to rewrite this code to first try
the allocation and on success simply return. On failure you can continue with
the same code.
In 5.0 this "bug" is fixed. But the way MS programmes think seems
frightening.
Paul
... An Elephant. A mouse built to government specs
--- OS/2 Warp
---------------