I'm working on a large, aging code base for an MFC app. The code has been worked on by many developers over time, and as a result, we have three different ways throughout the code of dealing with the possibility of an allocation failure with new.

The first way is to test for NULL on the result of new. We don't use nothrownew.obj so this is clearly an error that needs to be cleaned up.

The second is to catch CMemoryException\* (yes, C++ exceptions are enabled in the compiler). From what I understand, MFC overrides the standard operator new, and throws this thing instead. I am fairly certain that this second method is correct in the MFC application itself. MFC overrides new, with its strange CMemoryException throwing version. 

The last comes from our base of people who are good with C++, but aren't neccessarily MFC programmers. They are catching const std::bad\_alloc&. 

What I really don't know is what to expect for static libraries linked into the application. This is were the vast majority of the code that uses bad\_alloc lives. Assuming these libraries are not compiled with MFC or ATL, and are written in standard C++ only, can they expect to catch bad\_alloc? Or will the presence of MFC in the application they link to infect them with the global new operator and render their attempts to fail cleanly on a bad allocation moot?

If you have an answer, could you explain how this works, or point me to the right reference to sort this out?