I am working on a large, outdated code base for an MFC application. Over time, the code worked by many developers, and as a result, we have three different ways of code related to the possibility of rejection of selection with a new one.
The first way is to check NULL for the result of new. We do not use nothrownew.obj, so this is clearly a bug that needs to be cleaned up.
The second is to catch a CMemoryException * (yes, C ++ exceptions are included in the compiler). From what I understand, MFC overrides the standard new operator and discards this thing instead. I am pretty sure that this second method is correct in the MFC application itself. MFC overrides the new one, with its weird version of CMemoryException metadata.
The latter comes from our database of people who are good with C ++, but not necessarily MFC programmers. They catch const std :: bad_alloc &.
I really don't know what to expect from the static libraries associated with the application. This was the vast majority of code that uses the life of bad_alloc. Assuming these libraries are not compiled with MFC or ATL and are written only in standard C ++, can they expect catch_alloc? Or will there be an MFC presence in the application that they are linking to infect them with a global new operator and make their attempts to fail on a bad distribution problem?
If you have an answer, could you please explain how this works or point me to the correct link to sort this?