假设有人简单地给您提供了一个没有背景的大型软件解决方案，那么他们是否仍在确定必须将解决方案编译/运行为32位还是64位？
答案 0 :(得分：1)
对于C或C ++，我将使用gcc -Og -Wall对其进行编译，分别使用-m32和-m64 进行编译。也许-Wextra。 （某些警告仅在启用了优化的情况下起作用，因此，仍然可以快速编译的最低优化级别优于-O0。）
还值得尝试使用clang，它具有不同的警告，有时甚至是更好的警告，和/或libstdc++而不是通常用于gcc的libstdc ++。
如果一个警告比另一个警告产生的警告多得多，尤其是有关类型不匹配或printf格式字符串的警告，则可能无法移植到该模式。
许多编译器警告旨在帮助捕获无法移植到32位或不能移植到64位的代码。当然，理想的情况（警告会鼓励这种情况）是在两者上均可使用的代码。
int和long在普通的32位x86 ABI中具有相同的大小，但是x86-64 System V具有64位long和指针。 Windows x64仅具有64位指针，而long仍为32位，因此这是不可移植的另一种方式。如果您要获取警告以指示指针指向long而不是intptr_t的指针，请不要忘记为Windows和Linux进行编译。和/或检测long是64位类型的假设。
如果您认为原始源可能已优化以避免在预期模式下进行填充，那么在结构布局中查找有关填充的警告可能会告诉您一些信息。
这不是万无一失的（有一些不可移植的方法不会生成警告），并且可能很难在总是产生很多警告的丑陋代码上使用。
我不认为这是您可以自动化的事情，因此我不确定这个问题对SO来说是否是主题。
我认为对可移植性问题有静态分析，因此，如果您考虑以编程方式检测到此问题，那么除了编译器警告外，这就是您要查看的内容。