我理解 - 例如 - int
的使用,在.NET中为System.Int32
,正在被nint
的使用所取代,这使得编译器能够编译代码为x64或x32。
但是与其他应用程序共享的代码呢,让我们说一个Android应用程序。据我所知nint
等仅适用于iOS和OS X,因此必须再次在该共享代码中使用int
。
具体示例可以是PCL,它链接到Xamarin.iOS应用程序。
会发生什么
int Add(int one, int two)
{
return one + two;
}
来自PCL的在iOS应用程序中使用时?
答案 0 :(得分:3)
取代
int
,在.NET中为System.Int32
,正在被nint
那是不对的。 int
保持不变,并且始终是32位整数。
一些Apple API(iOS和OSX)都使用NSInteger
等类型。这种类型是32位处理器上的32位,64位处理器上的64位。
这在.NET中不存在,最接近的是IntPtr
,这通常不是一种易于使用的类型。
在编写原始MonoTouch时,世界(至少是移动世界)是32位,API是使用System.Int32
绑定的。这种方法运作良好多年,但最终,64位世界变得流动起来。
这就是Xamarin引入nint
(以及nuint
和nfloat
)的原因。这些类型因CPU架构而异。它允许我们(和你)绑定API,就像Apple定义的那样(int
保持int
但NSInteger
变成nint
。
对于PCL(或共享代码),您应避免这些类型。它们并非在所有平台上都可用(即使复制了源,您也会错过它们上的JIT / AOT优化)。 IOW应该使用的唯一地方是您的平台特定代码(iOS和/或OSX)。
答案 1 :(得分:0)
现在我明白了。关键是,触发本机API的所有内容都需要(由编译器)准备好以x32或x64模式运行。这就是像nint这样的新类型。
所有不接触原生内容的东西仍然可以利用"本机.NET类型系统"包括Int32。这回答了上面的示例代码如何在PCL中起作用的问题:因为PCL代码永远不会依赖于原生API,所以没关系。