为什么/ Wp64已被弃用？

Question

为什么不推荐使用/Wp64 Visual C++中的标志？

cl:命令行警告D9035:
已弃用选项'Wp64',将来的版本中将删除该选项

Answer 1

我认为这/Wp64已被弃用,主要是因为编译64位目标会捕获它设计用于捕获的错误类型(/ Wp64仅在32位编译中有效).当64位目标出现时,该选项被添加回来帮助人们将程序迁移到64位并帮助检测不是"64位清理"的代码.

这里是种有问题的例子/Wp64,微软仅仅是不感兴趣的固定-也许这是正确的(从http://connect.microsoft.com/VisualStudio/feedback/details/502281/std-vector-incompatible-with- wp64-compiler-option):

实际上,STL并非故意不兼容/Wp64,也不是完全无条件地不兼容/Wp64.潜在的问题是/Wp64与模板的交互非常糟糕,因为__w64它没有完全集成到类型系统中.因此,如果vector<unsigned int>之前被实例化vector<__w64 unsigned int>,那么它们都会表现得像vector<unsigned int>,反之亦然.在x86上,SOCKET是一个typedef __w64 unsigned int.这不是显而易见的,但是vector<unsigned int>在你之前被实例化vector<SOCKET>,因为vector<bool>在我们的实现中得到了支持vector<unsigned int>.

以前(在VC9和更早版本中),/Wp64 模板和模板之间的这种不良交互引起了虚假警告.然而,在VC10中,对STL的改变使情况变得更糟.现在,当vector::push_back()给出一个向量本身的元素时,它会在做其他工作之前计算出元素的索引.该索引是通过从向量的开头减去元素的地址获得的.在你的repro中,这涉及减去const SOCKET * - unsigned int *.(后者是unsigned int *并且不是SOCKET *由于之前描述的错误.)这/应该/触发虚假警告,说"我在x86上减去指向相同类型的指针,但在x64上指向不同类型".但是,这里有一个第二个错误,它 /Wp64真的很混乱,并认为这是一个硬错误(同时添加常量unsigned int *).

我们同意这个虚假的错误信息令人困惑.但是,由于它之前是一个不可沉默的命令行弃用警告D9035,我们认为这应该足够了.D9035已经说不/Wp64应该使用了(虽然它没有继续说"这个选项是超级越战车,现在完全没必要").

在STL中,我们可以#error在何时/Wp64使用.但是,这会破坏仍在编译的客户/Wp64(尽管有弃用警告),并且不会触发此虚假错误.STL也可以发出警告,但编译器已经在发出D9035.