奔向64位：可移植性探讨
软件世界
可移植性的话题永远吸引着程序员的注意。Brian Kernighan和Rob Pike在《程序设计实践》第8章中强调：“只使用那些到处可用的语言特性”。如果你正是这么做的，那么你会发现下面的文章正是在描述你的业绩。
设计的底线
我们首先要了解，64位平台并不是平台的终结，应用程序消耗资源的速度向来都是超过平台设计者的想像的。所以，我们要在心中为今后的128位或是256位平台留好余地。但是无论如何，我们现在�*米�64位平台的东风，让自己的产品赢在起跑线上。第41期的《新平台下的数据类型》中我们谈到了64位特有的数据结构和类型，这些在128位平台中会得到保留，最少也应该是兼容──这是我们在设计时为了可移植性所要坚守的底线。
已有代码升迁
先来看一个细节，曾经值得信赖的printf()函数突然变得丑恶起来，“printf()函数基本转换表”中明白地写着“%x,X：无符号十六进制数(带前导0x或0X)”。但在64位的C中，它分化成了针对32位的“%I32x”和针对64位的“%I64x”。上帝啊，还有什么是可以依靠的？答案是流库，在基本输入和输出中，流库的接口在32位和64位之前保持不变性(consistency)，它是我们能够依靠的，并且可以预见在更新的平台中，它还将保持不变。
已经编译好的工程文件呢？它们还在吗？还可用吗？答案正如你的预期：不一定，非常老旧的代码、最新的代码和依附性较少的代码会得以生存。如果你使用的是16/32位的混合模式下的工程Visual Studio，你应该首先使用较早版本的Visual Studio.NET(如Visual Studio 2001或Visual Studio 2003)升迁你的工程文件，再利用Visual Studio 2005来升迁这些已经升迁到.NET平台下的工程。这种升级会有折损(loss)吗？如果转换成功了，一般就不会。否则，就根本成功不了。所以，渐进式的升级应该是一个很好的主意。
测试你的成果
能够正确编译的程序不等于能够正确运行的程序，截断有时会有警告，但对于切片(slicing)和赋值相容(由隐式转换引起)，编译器往往表现得很冷漠。为了验证你的32位对象是不是能够乖乖地在64位平台下继续表现正常，一个“/Wp64”是必不可少的编译开关，如果你的程序连它都可以Pass，那么基本上说，这个程序在移植性方面是过关了。