Xamarin到64位iOS/OSX平台的粗野过渡

　　当Xamarin开始自己的iOS项目的时候，设备仅能够在32位模式下使用，也就是32位版本的NSInteger和CGFloat。当他们开始调查64位OSX的时候，他们意识到自己对那些数据类型的假设是错误的。Miguel继续说：

我们将需要审计我们的所有API从而实现合适的类型映射，同时我们将破坏源码的兼容性，使用类似于下面的代码：

var foo = new Xxx ();
int count = foo.GetRowCount ();
// oops, can not cast a long into an int.

当我们把源码的破坏和Apple拥有一个32位兼容性故事，同时我们仅有一些遗留类库依赖于32位API的事实结合起来的时候，我们意识到我们并不急于转移到64位的世界。

　　随着仅能引入64位类库的Mountain Lion的出现，他们看到了改变这种设计的需要。而Apple提供32位和64位版本的iPhone 5的决定进一步加剧了这种局面。为了处理这些新的挑战，Xamarin已经创建了三个新的数据类型：

• nint
• nuint
• nfloat

　　这些新的结构被定义为32位或者64位，依赖于代码编译的目标平台。但是故事的内容远不止如此。原始的数学运算使用特殊的IL指令进行操作（例如加法），而用户定义的结构需要调用op_Addition方法。

　　对于性能敏感的代码而言这可能会引发一些小的但是值得注意的影响。因为在使用本地类库的时候这些类型是非常基础的，AOT编译器会被修改为重新解释使用这些类型的操作。Miguel继续说：

op_Addition调用最终会和本地ECMA CIL add指令一样。IL可能看起来很恐怖，但是本地代码也是如此。

　　一些人可能会想知道为什么Xamarin不使用IntPtr——支持平台特定整数的CLR数据类型。Miguel写道：

我们选择了nint和nuint而不是内置的IntPtr和UIntPtr，因为前者让人感觉是自然的“原生整型”，而IntPtr则是文化相关的，它已经有指针或者一个本地符号。另外，我们并没有等价的本地浮点类型。

我们选择避免使用名称NSInteger和CGFloat有几个方面的原因：一般情况下功能已经足够，它们可能值得在Mono中用于除了Mac和 iOS之外的地方；同时感觉这些是真正的VM支持的类型，而不是一些类型定义或者别名。在理想的情况下，这些最终会成为C#标准的一部分。

　　查看英文原文：Xamarin’s Rough Transition to 64-bit iOS/OSX