为什么不建议使用/ Wp64？ [英] Why is /Wp64 deprecated?

问题描述

为什么在Visual C ++中 / Wp64 标志已弃用？

cl：命令行警告D9035：

选项' WP64'已被弃用，并将在以后的版本中删除

解决方案

我认为<不建议使用code> / Wp64 主要是因为为64位目标进行编译将捕获其设计要捕获的各种错误（/ Wp64仅在32位编译中有效）。当出现64位目标时，会重新添加该选项，以帮助人们将程序迁移到64位并帮助检测并非 64位干净的代码。

以下是Microsoft不想解决的 / Wp64 这类问题的一个示例-可能正确地如此（来自 http://connect.microsoft。 com / VisualStudio / feedback / details / 502281 / std-vector-incompatible-with-wp64-compiler-option ）：

实际上，STL并非故意与 / Wp64 不兼容，
也并非完全无条件地与 / Wp64 。
的潜在问题是 / Wp64 与
模板的交互非常差，因为 __ w64 没有完全集成到类型系统中。
因此，如果在 vector< __ w64 unsigned int> 之前实例化 vector< unsigned int> 它们的行为类似于 vector< unsigned int> ，反之亦然。在x86上， SOCKET 是 __ w64 unsigned int 的typedef。这不是很明显，但是 vector< unsigned int> 会在您的 vector< SOCKET> 之前实例化
，因为 vector< bool> （在我们的
实现中）由 vector< unsigned int> 支持。 / p>

以前（在VC9及更早版本中）， / Wp64
与模板之间的这种不良交互会导致虚假警告。但是，在VC10中，STL对
的更改使情况变得更糟。现在，当 vector :: push_back（）被赋予
向量本身一个元素时，它会在执行其他工作之前先确定该元素的索引
。该索引是通过从向量的开头减去
元素的地址获得的。在您的复制程序中，
涉及减去 const SOCKET *-unsigned int * 。 （由于前面描述的
，后一个
是 unsigned int * 而不是 SOCKET * /应该/触发一个虚假警告，说我是
减去指向x86上相同类型但指向x64上
不同类型的指针。但是，这里有一个第二个错误，其中
/ Wp64 真的很困惑，并认为这是一个硬错误（而
在 unsigned int * ）。

我们同意此错误消息令人困惑。但是，由于
之前带有不可沉默的命令行弃用警告
D9035，因此我们认为这已经足够。 D9035已经说过
不应使用 / Wp64 （尽管它并没有继续说此
选项是超级傻瓜越野车，并且现在完全没有必要）。

在STL中，当时，我们可能会出现 #error / Wp64 。但是，这会使
破坏仍使用 / Wp64 进行编译的客户（尽管
弃用警告），并且不会触发此虚假错误。 STL
也可能会发出警告，但编译器已经发出了D9035。

Why is the /Wp64 flag in Visual C++ deprecated?

cl : Command line warning D9035 :
option 'Wp64' has been deprecated and will be removed in a future release

解决方案

I think that/Wp64 is deprecated mainly because compiling for a 64-bit target will catch the kinds of errors it was designed to catch (/Wp64 is only valid in 32-bit compiles). The option was added back when 64-bit targets were emerging to help people migrate their programs to 64-bit and help detect code that wasn't '64-bit clean'.

Here's an example of the kinds of problems with /Wp64 that Microsoft just isn't interested in fixing - probably rightly so (from http://connect.microsoft.com/VisualStudio/feedback/details/502281/std-vector-incompatible-with-wp64-compiler-option):

Actually, the STL isn't intentionally incompatible with /Wp64, nor is it completely and unconditionally incompatible with /Wp64. The underlying problem is that /Wp64 interacts extremely badly with templates, because __w64 isn't fully integrated into the type system. Therefore, if vector<unsigned int> is instantiated before vector<__w64 unsigned int>, then both of them will behave like vector<unsigned int>, and vice versa. On x86, SOCKET is a typedef for __w64 unsigned int. It's not obvious, but vector<unsigned int> is being instantiated before your vector<SOCKET>, since vector<bool> is backed (in our implementation) by vector<unsigned int>.

Previously (in VC9 and earlier), this bad interaction between /Wp64 and templates caused spurious warnings. In VC10, however, changes to the STL have made this worse. Now, when vector::push_back() is given an element of the vector itself, it figures out the element's index before doing other work. That index is obtained by subtracting the element's address from the beginning of the vector. In your repro, this involves subtracting const SOCKET * - unsigned int *. (The latter is unsigned int * and not SOCKET * due to the previously described bug.) This /should/ trigger a spurious warning, saying "I'm subtracting pointers that point to the same type on x86, but to different types on x64". However, there is a SECOND bug here, where /Wp64 gets really confused and thinks this is a hard error (while adding constness to the unsigned int *).

We agree that this bogus error message is confusing. However, since it's preceded by an un-silenceable command line deprecation warning D9035, we believe that that should be sufficient. D9035 already says that /Wp64 shouldn't be used (although it doesn't go on to say "this option is super duper buggy, and completely unnecessary now").

In the STL, we could #error when /Wp64 is used. However, that would break customers who are still compiling with /Wp64 (despite the deprecation warning) and aren't triggering this bogus error. The STL could also emit a warning, but the compiler is already emitting D9035.

这篇关于为什么不建议使用/ Wp64？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！