int64 ビット コンパイラで通常 32 ビットなのはなぜですか? 私がプログラミングを始めたとき、 int は通常、基礎となるアーキテクチャと同じ幅であると教えられました。そして、これも理にかなっていることに同意します。指定されていない幅の整数が基礎となるプラットフォームと同じ幅であることは論理的だと思います（ただし、このような狭い範囲intがほとんど適用されない8または16ビットマシンについて話している場合を除きます）。
後で、intほとんどの 64 ビット プラットフォームでは通常 32 ビットであることを知りました。では、その理由は何なのか気になります。データを格納するには、明示的に指定されたデータ型の幅を好むためint、パフォーマンス上の利点を提供しない の一般的な使用法を残します。少なくとも私のシステムでは、32 ビット整数と 64 ビット整数で同じパフォーマンスが得られます。そのため、バイナリメモリのフットプリントが残りますが、大幅ではありませんが、わずかに削減されます...
歴史、トレードオフ、および決定は、http://www.unix.org/whitepapers/64bit.htmlで The Open Group によって説明されています。さまざまなデータ モデル、それらの長所と短所、および 64 ビット コンピューティングに対応するために Unix 仕様に加えられた変更について説明します。
ints は、ほとんどの主要なアーキテクチャで長い間 32 ビットであったため、それらを 64 ビットに変更すると、解決するよりも多くの問題が発生する可能性があります。
私はもともとこの質問に答えてこれを書きました。一部修正しましたが、ほぼ同じです。
まず、 C++ ドラフトにあるように、プレーンな int を 32 ビットより広くすることができます。
注: プレーン int は、実行環境のアーキテクチャによって提案される自然なサイズを持つことを意図しています。その他の符号付き整数型は、特別なニーズを満たすために提供されています。— エンドノート
強調鉱山
これは、私の 64 ビット アーキテクチャ (および他のすべてのアーキテクチャ) では、プレーンな int のサイズは 64 ビットである必要があると表向きは言っているように思われます。それはアーキテクチャによって提案されたサイズですよね? ただし、 64 ビット アーキテクチャの自然なサイズは32 ビットであると断言しなければなりません。仕様の引用は、主に 16 ビットのプレーン int が必要な場合 (仕様で許可されている最小サイズ) のためにあります。
最大の要因は規則です。32 ビットのプレーンな int を持つ 32 ビット アーキテクチャから移行し、そのソースを 64 ビット アーキテクチャに適合させることは、設計者とそのユーザーの両方にとって、2 つの異なる方法で 32 ビットのままにしておくと単純に簡単になります。
1 つ目は、システム間の違いが少ないほど、誰にとっても簡単になるということです。システム間の不一致は、ほとんどのプログラマにとって頭の痛い問題でした。これらは、システム間でコードを実行するのを難しくするだけです。32ビットと64ビットだけの同じディストリビューションのコンピューター間で実行できないという比較的まれなケースに追加されます. しかし、John Kugelman が指摘したように、アーキテクチャは 16 ビットから 32 ビットの単純な int になりました。そのための面倒な作業を経て、今日もそうすることができます。これは彼の次のポイントにつながります。
より重要なコンポーネントは、整数サイズまたは新しい型が必要になるというギャップです。sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)は実際の仕様にあるため、プレーンな int を 64 ビットに移動するとギャップが強制されます。シフトから始まりlongます。プレーンな int が 64 ビットに調整された場合、sizeof(int) <= sizeof(long)強制的longに少なくとも 64 ビットになる制約があり、そこからサイズに固有のギャップがあります。longまたはプレーン int は通常 32 ビット整数として使用され、現在はどちらも使用できないため、使用できるデータ型はもう 1 つだけですshort。単純にそのサイズを破棄すると、最小で 16 ビットになるためshort、理論的には 32 ビットになり、そのギャップを埋めることができますがshort、スペースを最適化することを目的としているため、小さい 16 ビットの整数の使用例もあります。サイズをどのように配置しても、幅が失われるため、 int のユースケースは完全に利用できません。幅が広ければ良いというわけではありません。
これは、仕様の変更が必要であることを意味しますが、設計者が不正を行ったとしても、変更によって破損したり、時代遅れになったりする可能性が非常に高くなります。長期的なシステムの設計者は、システム内の独自のコード、依存関係、および実行したいユーザーのコードの両方の絡み合ったコードのベース全体を使用する必要があり、その影響を考慮せずに膨大な量の作業を行うことは、単に賢明ではありません。 .
補足として、アプリケーションが 32 ビット以上の整数と互換性がない場合は、static_assert(sizeof(int) * CHAR_BIT <= 32, "Int wider than 32 bits!");. ただし、仕様が変更されて 64 ビットのプレーンな int が実装される可能性があることは誰にもわかりません。そのため、将来的に保証したい場合は、静的アサートを行わないでください。
主な理由は下位互換性です。さらに、すでに 64 ビット整数型longがあり、float 型についても同じことが言えます:floatおよびdouble. これらの基本型のサイズをアーキテクチャごとに変更しても、複雑になるだけです。また、32 ビット整数は範囲の面で多くのニーズに対応します。
まだ誰もこれを指摘していないので。
int-32767 から 32767( ) の間であることが保証さ2^16れています。これは標準で要求されています。すべてのプラットフォームで 64 ビットの数値をサポートしたい場合は、long long( -9223372036854775807 から 9223372036854775807 まで) をサポートする適切なタイプを使用することをお勧めします。
int規格で要求される最小範囲を提供する限り、任意の値を指定できます。