为什么微软仍然支持nothrownew.obj？
根据 MSDN，Microsoft 仍然随 Visual C++ 10 提供 nothrownew.obj (Visual Studio 2010) 运行时库，以便用户可以链接到它并具有“普通”（不是 nothrow 风格）new 返回 null 的不标准行为关于分配失败。这种不合标准的行为可以追溯到 Visual C++ 6，现在它被认为是非常古老的。
为什么会这样做呢？我的意思是他们使编译器的每个新版本越来越符合标准。例如，Visual C++ 7 支持“default int”，但 Visual C++ 9 则不支持。通过稍微更改代码以使用 new 的 nothrow 风格，可以轻松实现 new 的旧的不合标准行为 - 这是简单且非常简单的简单的。
为什么这个选项如此重要以至于 Microsoft 仍然支持它？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
嗯，这是一个悬而未决的问题，因为除了微软的负责人之外，没有人可以肯定地说——如果有的话。所以，我会咬一口：
我猜这是为了方便：
也就是说，删除它可能比保留它更麻烦。
至少他们需要/应该在删除版本之前提供已弃用的通知。我不知道他们是否在 VS2010 或任何之前的版本中这样做。
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:
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.
因为我现在（2012 年）将产品从 Visual C++ 6.0 移植到 Visual Studio 2010，这对加快开发速度有很大帮助。我们也不会在未来几年内进行 Unicode 过渡。如果微软不提供兼容性功能，我会自己构建它。
附带说明一下，我们是专业领域的主要 ISV。如果我们决定改变操作系统，整个行业可能都会改变。 （在 Windows 之前，我们也曾经构建过专门的操作系统。）
Because I am now (2012) porting a product from Visual C++ 6.0 to Visual Studio 2010 and that helps greatly to bring the development up to speed. We also will not make the Unicode transition for a few years to come. If Microsoft would not provide the compatibility feature I would build it myself.
As a side note we are a major ISV in a specialized field. If we decide to change OS, an entire Industry would probably change to. (Before Windows we used to also build a specialised OS.)