なぜ C と C++ の基本型は、 がint常に 4 バイト、longが 8 バイトなどである Java のように厳密に定義されないのでしょうか。私の知る限り、C と C++ では のみがchar1 バイトとして定義され、その他はコンパイラによって定義が異なります。そのため、C と C++ の は、 より長く、より長ければint、必ずしも 4 バイトである必要はありません。なぜそうなるのか、また、それが何かの目的を果たすのか疑問に思いました。shortshortchar
ベストアンサー1
その理由は主に、C がはるかに幅広いプラットフォームに移植可能であるためです。さまざまなデータ型がさまざまなプラットフォームでさまざまなサイズになっているのには多くの理由がありますが、少なくとも歴史的には、intプラットフォームのネイティブ ワード サイズに適応してきました。PDP-11 では 16 ビット (long元々は 32 ビットの数値用に発明されました) でしたが、一部の組み込みプラットフォーム コンパイラでは 8 ビットの もありますint。32 ビット プラットフォームが登場し、32 ビットintの が使用されるようになると、short16 ビットの数値を表すために が発明されました。
現在、ほとんどの 64 ビット アーキテクチャでは、元々 32 ビット プラットフォーム用に作成された C プログラムの大規模なベースとの互換性を保つために 32 ビット を使用していますが、初期の Cray プラットフォームの一部をはじめ、int64 ビット を備えた 64 ビット C コンパイラも存在していました。int
また、コンピューティングの初期の頃は、浮動小数点の形式とサイズは一般にあまり標準化されていませんでした (IEEE 754 は 1985 年まで登場しませんでした)。そのため、floats とdoubles は整数データ型よりもさらに定義が不十分です。通常、無限大、NaN、符号付きゼロなどの特殊性が存在することさえ想定されていません。
charさらに、a は1 バイトとして定義されているのではなく、1 を返すものとして定義されているとも言えるでしょうsizeof。これは必ずしも 8 ビットである必要はありません。(完全性のために、ここで「バイト「 」という用語は、普遍的に 8 ビットであると定義されているわけではありません。歴史的にはさまざまな定義があり、ANSI C 標準のコンテキストでは、「バイト」は実際にはchar、 の性質に関係なくを格納できる最小のストレージ単位として定義されていますchar。
36 ビットの PDP-10 や 18 ビットの PDP-7 などのアーキテクチャも C プログラムを実行できます。これらは現在では非常にまれですが、C データ型が 8 ビット単位で定義されない理由を説明するのに役立ちます。
最終的に、この言語がJavaのような言語よりも「移植性が高い」ものになるかどうかは議論の余地があるかもしれないが、Javaプログラムを16ビットプロセッサで実行するのは確かに最適とは言えず、36ビットプロセッサで実行するのはかなり奇妙である。言語移植性は高くなりますが、その言語で書かれたプログラムの移植性は低くなります。
編集：いくつかのコメントへの返答として、私は意見として、言語としての C は、企業や標準化団体によって多かれ少なかれ「所有」されている Java/Haskell/ADA のような言語とは異なることを付け加えておきたいと思います。ANSI C は確かに存在しますが、C は ANSI C 以上のものです。C は生きたコミュニティであり、ANSI 互換ではないがそれでも「C」である実装が多数存在します。8 ビットの を使用する実装がintC であるかどうかを議論することは、ほとんど無意味であるという点でスコットランド語が英語であるかどうかを議論することに似ています。8 ビットを使用するのには十分な理由があり、C を十分に知っている人なら、そのようなコンパイラ用に書かれたプログラムについて推論できないはずはなく、そのようなアーキテクチャ用に C プログラムを書く人は、自分のが 8 ビットであることをints望むでしょう。int