VS .NET 2003 When tracing C++ code in the debugger, it will always get out of sync and highlight the wrong line of code as you step through/in code. This makes it very hard to debug! Normally (under VC6 etc) this means that the code/source don't match, a rebuild all should probably be done. But this doesn't seem to help, and I'm 100% sure that the source I am trying to trace is the same source that was complied :) Anyone notice this problem and/or have a solution? -Troy PS: This happens even when building a simple dummy application, but only in source files that you add to the project.

Yep, and that is what happens when MFC calls new and it fails. But what happens if you call STL or your own funtions from within an MFC function override and your new handler is called throwing bad_alloc? It appears that MFC wont catch it, you will get an unhandled exception. If you try to recover from it, you might leak MFC resources. PS: Did this change in VC .NET? Or does new still return NULL?

We are all aware that by default VC++ implementation of NEW does not throw an exception (as it should based on C++ standards). MSDN has an article related to using set_new_handler() to make new throw std::bad_alloc when it fails instead of returning NULL. My question is how is that handled in an MFC app? For instance lets say you have a method named Foo(), and Foo() might throw std::bad_alloc due to it calling new internally. If you called Foo() from an MFC class method you override, and did not have a try/catch, would MFC catch the bad_alloc? In fact, what impact does it have at all on MFC if you change NEW to throw? I'm also curious how other developers handle NEW... Do you leave it returning NULL by default? If so, won't that cause problems if you use STL and an STL method calls new and it throws?