エンディアンとその意味について数え切れないほどの参考文献を見てきました。私はそれについて何の問題もありません...しかし、私のコーディングプロジェクトは、標準の「ゲーマー」ハードウェアで、LinuxとWindowsで実行する単純なゲームです。この場合、エンディアンを気にする必要がありますか? いつ心配する必要がありますか?私のコードは単純な C と SDL+GL です。複雑なデータは基本的なメディア ファイル (png+wav+xm) だけで、ゲーム データはほとんどが文字列、整数ブール値 (フラグなど)、および静的サイズの配列です。これまでのところ、問題が発生したユーザーはいないので、チェックを追加する必要があるかどうか疑問に思っています (後で実行されますが、IMO にはもっと緊急の問題があります)。
7 に答える
エンディアンを気にする必要がある場合:
- マシンまたはプロセス間で (ネットワークまたはファイルを使用して) バイナリ データを送信している。マシンのバイト オーダーが異なる場合や、使用するプロトコルが特定のバイト オーダーを指定している場合 (指定する必要があります)、エンディアンに対処する必要があります。
- さまざまなタイプのポインターを介してメモリにアクセスするコードがあります (たとえば、
unsigned int
を介して変数にアクセスするとしますchar*
)。
これらのことを行うと、知っているかどうかに関係なく、バイトオーダーを扱っています-コードがそうでない限り、それが何らかの方法であると想定して扱っている可能性があります。別のプラットフォームに対処する必要があります。
同様に、通常、同じケースで同様の理由でアライメントの問題に対処する必要があります。繰り返しますが、プラットフォームの境界を越える必要がないため、何もせずにすべてを正常に動作させることで対処している可能性があります (それが要件になった場合、後で戻ってくる可能性があります)。
「標準のゲーマー ハードウェア」で PC を意味する場合、x86/x64 では常にリトル エンディアンであるため、エンディアンについて心配する必要はありません。ただし、プロジェクトを他のアーキテクチャに移植する場合は、エンディアンに依存しないように設計する必要があります。
ネットワークからデータを受信/送信するときはいつでも、ネットワークとホストのバイトオーダーとの間で変換することを忘れないでください。C関数などhtons
、htonl
またはあなたの言語の同等のものをここで使用する必要があります。
ファイルからマルチバイト値 (UTF-16 文字や 32 ビット整数など) を読み取るときはいつでも、そのファイルはエンディアンが異なるシステムで作成された可能性があるためです。ファイルが UTF 16 または 32 の場合、おそらく BOM (バイト オーダー マーク) があります。それ以外の場合、ファイル形式は何らかの方法でエンディアンを指定する必要があります。
ゲームを異なるハードウェア アーキテクチャで実行する必要がある場合にのみ、これについて心配する必要があります。Intel ハードウェアで常に実行されることに自信がある場合は、忘れて構いません。多くの人が Intel とは異なるアーキテクチャを使用しているにもかかわらず、Linux で実行する場合は、それについて考える必要があるかもしれません。
ゲームをソース コード形式で配布していますか?
ゲームをバイナリのみとして配布している場合、ゲームが実行されるプロセッサ ファミリを正確に把握できるからです。また、メディア ファイルはユーザーが生成したものですか (おそらくレベル エディターを介して)、それとも本当に自分で提供するだけのものですか?
これが真にクローズドな環境 (配布するバイナリとゲーム アセットがカスタマイズされることを意図していない) である場合、エンディアンに対するリスクを知っているので、個人的にはだまされません。
ただし、ソースを配布している場合や、人々がゲームをカスタマイズすることを望んでいる場合は、懸念が生じる可能性があります。ただし、最近ではほとんどのデスクトップ/ラップトップ コンピュータが x86 に移行しているため、この懸念は薄れていると思います。
この問題は、ネットワークとデータの送信方法、および異なるプロセッサでデータを異なる方法でメモリに格納する可能性があるため、異なるプロセッサでビット操作を行っているときに発生します。