Share via

iOS および macOS のネイティブ型

  • [アーティクル]

Mac および iOS API では、アーキテクチャ固有のデータ型 (常に 32 ビット プラットフォームでは 32 ビット、64 ビット プラットフォームでは 64 ビット) を使用します。

たとえば、Objective-C では、NSInteger データ型を 32 ビット システムでは int32_t に、64 ビット システムでは int64_t にマップします。

この動作に対応するために、Unified API では、以前使用されていた int (.NET では常に System.Int32 と定義されています) を新しい System.nint データ型に置き換えます。 "n" は "native (ネイティブ)" を意味するため、そのプラットフォームのネイティブ整数型と考えることができます。

これらの新しいデータ型を使用すると、同じソース コードが、コンパイル フラグに応じて 32 ビットアーキテクチャと 64 ビット アーキテクチャ用にコンパイルされます。

新しいデータ型

次の表は、この新しい 32/64 ビットの環境に対応するためのデータ型の変化を示しています。

ネイティブ型 32 ビット バッキング型 64 ビット バッキング型
System.nint System.Int32 (int) System.Int64 (long)
System.nuint System.UInt32 (uint) System.UInt64 (ulong)
System.nfloat System.Single (float) System.Double (double)

お使いの C# コードが現在のものとほぼ同じに見えるように、これらの名前を選択しました。

暗黙の型変換と明示的な型変換

新しいデータ型の設計は、1 つの C# ソース ファイルで、ホスト プラットフォームとコンパイル設定に応じて 32 ビットまたは 64 ビット ストレージを自然な形で使用できるようにすることを目的としています。

そのために、プラットフォーム固有のデータ型から .NET 整数および浮動小数点データ型への暗黙的および明示的な変換セットを設計する必要がありました。

暗黙的な変換演算子は、データ損失の可能性がない (32 ビット値が 64 ビット空間に保存される) 場合に提供されます。

明示的な変換演算子は、データ損失の可能性がある (64 ビット値が 32 ビットまたは 32 ビットの可能性がある保存場所に保存される) 場合に提供されます。

int、uint、float はすべて暗黙的に nint、nuint、nfloat に変換可能です。32 ビットは常に 32 または 64 ビットに収まるからです。

nint、nuint、nfloat はすべて暗黙的に long、ulong、double に変換可能です。32 または 64 ビット値は常に 64 ビット ストレージに収まるからです。

nint、nuint、nfloat から int、uint、float へは明示的な変換を使用する必要があります。これらのネイティブ型には 64 ビットのストレージが保持される可能性があるためです。

long、ulong、double から nint、nuint、nfloat へは明示的な変換を使用する必要があります。これらのネイティブ型には 32 ビットのストレージのみを保持できると考えられるためです。

CoreGraphics 型

CoreGraphics で使用されるポイント、サイズ、四角形のデータ型では、これらが実行されているデバイスに応じて 32 または 64 ビットを使用します。 最初に iOS および Mac API をバインドしたときは、ホスト プラットフォームのサイズ (System.Drawing のデータ型) と偶然一致した既存のデータ構造を使用しました。

Unified に移行するときは、次の表に示すように、System.Drawing のインスタンスをそれに対応する CoreGraphics に置き換える必要があります。

System.Drawing の以前の型 新しいデータ型 CoreGraphics 説明
RectangleF CGRect 浮動小数点の四角形情報を保持します。
SizeF CGSize 浮動小数点のサイズ情報 (幅、高さ) を保持します
PointF CGPoint 浮動小数点のポイント情報 (X、Y) を保持します

以前のデータ型では float を使用してデータ構造の要素を保存していましたが、新しいものでは System.nfloat を使用します。