コードを 32 ビットと 64 ビットの両方のプラットフォームで正しく実行するには、どのような考慮事項が必要ですか?
編集:文字列/文字の印刷や構造の使用など、どのような領域に注意する必要がありますか?
コードを 32 ビットと 64 ビットの両方のプラットフォームで正しく実行するには、どのような考慮事項が必要ですか?
編集:文字列/文字の印刷や構造の使用など、どのような領域に注意する必要がありますか?
オプション:
仮想マシンを使用して何らかの言語(Java など)でコーディングします。
.NET でコーディングし、特定のアーキテクチャをターゲットにしないでください。.NET JIT コンパイラは、実行前に適切なアーキテクチャにコンパイルします。
1 つの解決策は、両方のプラットフォームで実行される仮想環境をターゲットにすることです (ここでは Java または .Net を考えています)。
または、インタープリター言語を選択します。
既存のコードやライブラリの呼び出しなど、その他の要件はありますか?
移植可能なコードを確実に書くために、ずっとやるべきだったのと同じこと:)
mozilla ガイドラインとC faqは良い出発点です
個々のプラットフォームごとに個別にコンパイルすることについてまだ話していると思いますか? 両方で実行することは、32 ビット バイナリを作成するだけで完全に実行可能です。
最大の問題は、ポインタを 32 ビットのストレージ ロケーションに置かないようにすることです。
しかし、この質問に対する適切な「言語にとらわれない」答えはありません。標準の 'C' や 'C++' のようなものに自分自身を制限した場合、特に確固たる答えを得ることができませんでした。データ ストレージ、ポインターなどのサイズはすべて実装に大きく依存します。
C# や Java などのマネージ言語、または JavaScript、Python、PHP などのスクリプト言語は、現在の方法論に縛られており、開始して高度なものを超えて何かを行うために心配する必要はあまりないため、正直なところ言語に依存します。 .
しかし、私の推測では、C++、C、およびその他の低レベル言語などの言語について尋ねていると思います。
32 ビットの世界では 2^32 の累乗に制限されていますが、64 ビットの世界では 2^64 の累乗に制限されているため、最大の懸念事項はサイズです。
64 ビットでは、メモリと RAM のストレージ用に大きなスペースがあり、より大きな数を計算できます。ただし、32 と 64 の両方でコンパイルすることがわかっている場合は、システムに対する期待を 32 ビットの世界に制限し、バッファーと数値の制限を確実に制限する必要があります。
C (およびおそらく C++) では、malloc のバッファー サイズを計算するときに常に sizeof 演算子を使用することを忘れないでください。このようにして、とにかく移植性の高いコードを記述し、これにより自動的に 64 ビット データ型が考慮されます。
ほとんどの場合、両方のプラットフォーム用にコードをコンパイルするだけで済みます。(これは、コンパイル済み言語を使用していることを前提としています。コンパイル済み言語を使用していない場合は、おそらく何も心配する必要はありません。)
問題を引き起こす可能性があると私が考えることができる唯一のことは、データ型のサイズを想定することです。これは、とにかく行うべきではないことです。もちろん、アセンブリで書かれたものはすべて問題を引き起こします。
「int」がシステムで最速の数値操作子である必要があることを考えると、多くのコンパイラは基礎となるアーキテクチャに基づいて整数のサイズを選択することに注意してください (いくつかの理論によると)。
これが、非常に多くのプログラマーが最も移植性の高いプログラムに typedef を使用する理由です。コードを 8 ビット プロセッサから 64 ビット プロセッサまでのすべてのプロセッサで動作させたい場合は、とにかく C では int が厳密に定義されていないことを認識する必要があります。
ポインターも注意が必要な領域です。ポインターの数値をいじる場合は、long、long long、または特定の型を使用しないでください。適切な構造を使用してください。残念ながら、コンパイラーごとに異なります (これが、使用するコンパイラごとに個別の typedef.h ファイルがある理由です)。
-アダム・デイビス