Question

According to MSDN, Microsoft still ships nothrownew.obj with the Visual C++ 10 (Visual Studio 2010) runtime library, so that users can link against it and have sub-standard behavior of “ordinary” (not nothrow flavor) new returning null on allocation failure. This sub-standard behavior dates back to Visual C++ 6 which is now considered extremely old.

Why would it do so? I mean they make each new version of the compiler more and more Standard-compliant. For example, Visual C++ 7 would support “default int”, but Visual C++ 9 would not. And the old sub-standard behavior of new can be easily achieved by slightly changing code to use nothrow flavor of new – this is straightforward and very easy.

Why is this option so important that Microsoft still supports it?

Answer 1

Well, this is sort of an open question, since nobody except someone responsible from Microsoft can say for sure – if at all. So, I’ll take a bite:

I’ll guess it is for convenience:

1. Microsoft itself may need it in some of their products and it is just easier having it together with the compiler tools.
2. Microsoft may know that someone (say a big vendor/app) still needs it and it is just easier (or even necessary if compiler specific) to still provide it.
3. Microsoft may know/anticipate that it is generally still “widely” used in legacy apps. Big or small.
4. “It doesn’t hurt”, well arguably. For example, Microsoft has a long record of maintaining backward compatibility in Windows (see Raymond Chens blog), again, arguably not always for the better.
5. Documentation, Tests, etc. would need to be altered (or removed, but still).

That is, removing it may be more trouble yet then just keeping it.

At least they need / should provide a deprecated notice a version prior to removing it. I don’t know if they did that for VS2010 or any prior version.