为什么Visual C ++ deprecated中的/Wp64标志？
cl：命令行警告D9035：
选项'Wp64'已被弃用，将在以后的版本中删除
答案 0 :(得分：17)
我认为/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是__w64 unsigned int的typedef。这并不明显，但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（虽然它不会继续说“这个 选项是super duper buggy，现在完全没必要“）。在STL中，我们可以
#error使用/Wp64。但是，那会 打破仍在使用/Wp64进行编译的客户（尽管如此） 弃用警告）并没有触发这个虚假错误。 STL 也可以发出警告，但编译器已经在发出D9035。
答案 1 :(得分：4)
/ Wp64是浪费时间。它已被弃用，这种弃用是有道理的。 / Wp64在32位构建上的工作方式是在类型上寻找_w64注释。这个_w64注释会告诉编译器，即使这种类型在32位模式下是32位，在64位模式下也是64位。事实证明这很有趣，尤其是涉及模板的地方。
64位版本上的/ Wp64非常有用。文档（http://msdn.microsoft.com/en-us/library/vstudio/yt4xw8fh.aspx）声称它在64位版本中默认启用，但事实并非如此。仅在显式设置/ Wp64时才会发出编译器警告C4311和C4312。这两个警告表示何时将32位值放入指针，反之亦然。这些对于代码正确性非常重要，并声称处于警告级别1.我发现了非常广泛的代码中的错误，如果开发人员为64位版本启用了/ Wp64，则会停止这些错误。不幸的是，您还会收到您观察到的命令行警告。我知道没有办法压制这个警告，我已经学会了忍受它。好的一面是，如果您使用错误警告进行构建，则此命令行警告不会变为错误。
答案 2 :(得分：2)
因为当使用VS2010的64位编译器时，编译器会自动检测64位问题...当你可以尝试检测运行32位编译器的64位问题时，此开关是从后面开始...
请参阅http://msdn.microsoft.com/en-us/library/yt4xw8fh%28v=VS.100%29.aspx
答案 3 :(得分：0)
您可以链接到弃用警告，但无法转到/Wp64文档？
默认情况下，Visual C ++ 32位编译器和Visual C ++ 64位编译器中的/ Wp64编译器选项处于关闭状态。
如果您使用64位编译器定期编译应用程序，则可以在32位编译中禁用/ Wp64，因为64位编译器将检测所有问题。
强调添加