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は3つの新しいデータ型を作成しました.

nint

nuint

nfloat

これらの新しい構造は、コードコンパイルのターゲットプラットフォームに依存する32ビットまたは64ビットとして定義される.しかし、物語の内容はそれだけではない.元の数学演算は特殊なIL命令(例えば加算)を用いて動作し,ユーザ定義の構造はop_を呼び出す必要がある.Additionメソッド.
パフォーマンスに敏感なコードでは、小さな影響を及ぼす可能性がありますが、注意すべき影響があります.ローカルクラスライブラリを使用する場合、これらのタイプは非常に基礎的であるため、AOTコンパイラはこれらのタイプを使用する操作を再解釈するように変更されます.Miguelは続けた.
op_Addition呼び出しは最終的にローカルECMA CIL add命令と同じになります.ILは怖そうに見えるかもしれませんが、ローカルコードもそうです.
Xamarinがプラットフォームの特定の整数のCLRデータ型をサポートするIntPtrを使用しない理由を知りたい人もいるかもしれません.Miguelはこう書いています.
内蔵のIntPtrやUIntPtrではなくnintとnuintを選びました.前者は自然な「原生整型」と感じさせますが、IntPtrは文化関連で、ポインタやローカル記号があります.また,等価なローカル浮動小数点タイプはない.
NSIntegerとCGFloatの名前の使用を避けるにはいくつかの理由があります.一般的には、MacとiOS以外の場所でMonoで使用する価値がある可能性があります.また、これらは、いくつかのタイプ定義や別名ではなく、真のVMがサポートするタイプだと感じます.理想的には、これらは最終的にC#標準の一部になります.
Xamarin’s Rough Transition to 64-bit iOS/OSX