可変幅タイプは、最新のCの固定タイプに置き換えられましたか？

本日、Code Reviewのレビューで興味深い点に出会いました。@Veedracはにrecommened この回答可変サイズの種類（たとえばことintとがlong）のような固定サイズの種類に置き換えることuint64_tとuint32_t。その答えのコメントからの引用：

intおよびlongのサイズ（およびそれらが保持できる値）はプラットフォームに依存します。一方、int32_tは常に32ビット長です。intを使用するということは、コードがプラットフォームごとに異なる動作をすることを意味しますが、これは一般的には望んでいないことです。

共通の型を修正しないという標準の背後にある理由は、@ supercatによって部分的に説明されています。Cは、当時システムプログラミングに通常使用されていたアセンブリとは対照的に、アーキテクチャ間で移植できるように作成されました。

設計意図はもともと、int以外の各タイプがさまざまなサイズの数を処理できる最小のものであり、そのintが+/- 32767を処理できる最も実用的な「汎用」サイズであると思いました。

私については、私はいつも使用intしており、代替案についてはあまり心配していません。私はいつも、これが最高のパフォーマンス、ストーリーの終わりを持つ最もタイプだと思っていました。固定幅が便利だと思った唯一の場所は、ストレージ用またはネットワーク経由の転送用にデータをエンコードする場合です。他の人が書いたコードで固定幅タイプを見ることはめったにありません。

私は70年代に行き詰まっintていますか、それともC99以降の時代に使用する理論的根拠はありますか？

型がuint32_tプログラマーのサイズを心配することから救うといったタイプの一般的で危険な神話があるint。規格委員会がマシンに依存しないセマンティクスで整数を宣言する手段を定義すると役立つと思いuint32_tますが、署名のないタイプには、コードがクリーンで移植性のある方法で記述できないほど緩いセマンティクスがあります。さらに、int32多くのアプリケーションの方法で不必要に厳密に定義されたセマンティクスを持つような署名付きタイプは、そうでなければ有用な最適化を排除します。

例えば、考慮してください：

uint32_t upow(uint32_t n, uint32_t exponent)
{
  while(exponent--)
    n*=n;
  return n;
}

int32_t spow(int32_t n, uint32_t exponent)
{
  while(exponent--)
    n*=n;
  return n;
}

int4294967295を保持できないマシン、または18446744065119617025を保持できるマシンではn、とのすべての値に対して最初の関数が定義されexponent、その動作はのサイズの影響を受けませんint。さらに、標準では、それは、任意のサイズでマシン上で異なる動作をもたらすことを必要としないであろうint いくつかの値nとexponent、しかし、それは4294967295はとして表現されるマシン上で未定義の動作を起動するようになりますintが、18446744065119617025ではありません。

第二の機能は、いくつかの値に対して、未定義の動作が得られますnし、exponentマシン上でint4611686014132420609を保持することはできませんが、すべての値に対して定義された動作が得られますnし、exponentそれは（のための仕様ができ、すべてのマシン上でint32_tそれのマシン上の2の補数ラッピング行動を暗示しますより小さいint）。

歴史的に、規格はコンパイラがintオーバーフローで何をすべきかについて何も述べていませんでしたがupow、コンパイラは、あたかもintオーバーフローしないほど十分に大きいかのように一貫して同じ動作をもたらしました。残念ながら、一部の新しいコンパイラは、標準で義務付けられていない動作を排除することにより、プログラムを「最適化」しようとする場合があります。

バッファーサイズ、配列インデックス、Windows 'などのポインター（したがって、アドレス可能なメモリの量）に密接に関連する値の場合lParam、アーキテクチャに依存するサイズの整数型を持つことは理にかなっています。したがって、可変サイズの型は依然として有用です。これは、私たちがのtypedefを持っている理由であるsize_t、ptrdiff_t、intptr_t、など彼らが持っている組み込みのC型の整数のいずれもポインタのサイズする必要はないので、typedefであることを。

質問があるので、本当にいるかどうかchar、short、int、long、とlong longまだ便利です。

IME、CやC ++プログラムがintほとんどのものに使用することは今でも一般的です。ほとんどの場合（つまり、数値が±32 767の範囲にあり、厳しいパフォーマンス要件がない場合）、これは問題なく機能します。

しかし、17〜32ビットの範囲の数値（大都市の人口など）を処理する必要がある場合はどうでしょうか。を使用できますintが、プラットフォームの依存関係をハードコーディングすることになります。厳密に標準に準拠する場合はlong、少なくとも32ビットが保証されているを使用できます。

問題は、C標準が整数型の最大サイズを指定していないことです。long64ビットの実装があり、メモリ使用量が2倍になります。そして、これらlongが数百万のアイテムを持つ配列の要素である場合、あなたは狂ったようにメモリをスラッシングします。

したがって、プログラムをクロスプラットフォームとメモリ効率の両方にしたい場合は、ここで使用するのに適したタイプintでlongはありません。を入力しint_least32_tます。

• I16L32コンパイラは32ビットlongを提供し、以下の切り捨ての問題を回避します。int
• I32L64コンパイラは32ビットintを提供し、64ビットのメモリの浪費を回避しますlong。
• I36L72コンパイラは36ビットを提供します int

OTOH、あなたが思うしていない膨大な数や巨大な配列を必要とするが、あなたはスピードを必要としています。またint、すべてのプラットフォームで十分な大きさかもしれませんが、必ずしも最速の型であるとは限りませんint。通常、64ビットシステムにはまだ32ビットがあります。しかし、あなたは使用することができint_fast16_t、それはだかどうかを、「最速」型を取得int、longまたはlong long。

したがって、の型には実用的なユースケースがあります<stdint.h>。標準の整数型は何の意味もありません。特にlong、32ビットまたは64ビットである可能性があり、コンパイラー作成者の気まぐれに応じて、ポインターを保持するのに十分な大きさである場合とそうでない場合があります。