0

C99 と C11 (少なくともそれらの最終ドラフト) の両方で、 、 、 、 in の存在がuint_least8_t署名uint_least16_tさuint_least32_tれuint_least64_tた<stdint.h>バリアントと共に必要であることがわかりました。

1 から 64 までuint_least{N}_tのすべてのNが利用可能であるという要件は合理的だと思います。これが当てはまらない正当な理由はありますか？実装が 8、16、32、および 64 を提供する必要がある場合、 Nのすべてのより小さい値の実装が実現可能であることは確かです (たとえばtypedef uint_least16_t uint_least15_t;、x86 の場合などは明らかです)。

私が尋ねているuint_least21_tのは、単一の Unicode コードポイントを格納する型が必要であることに気付いたからです。これは、その値U+0000をU+10FFFF含む (Unicode 4.0 で導入された制約) の間の任意の値を持つことができます。一部のターゲット アーキテクチャに (たとえば) 高速な 24 ビット整数が含まれている場合は、これがより正確な選択になると思います。現在、私は大きなプリプロセッサ セクションで立ち往生しており、適切な型を選択するために 21 から 32 までのNdefined(UINT_LEAST{N}_MAX)をテストしています。

4

1 に答える 1

1

1999 年以降の最新のハードウェア (およびコンパイラ) のほとんどは、8、16、32、および 64 ビットの符号なし型を合理的に実装できます。実際、かなりの数の最新の実装でunsigned charは、、、、、およびARE が 8、16、32 unsigned short、および 64 ビットの符号なし型として実装されていますが、厳密に言えば、これは許可されていますが、必須ではありません。unsigned longunsigned long long

つまり、コンパイラ ベンダーにとってuint_least8_t、uint_least16_t、uint_least32_t、 uint_least64_tは簡単にサポートできます。コンパイラ ベンダーは強い抵抗を示しません。

他のそのようなタイプには当てはまりません。たとえば、N の他の値に対して形式uint_leastNの符号なし整数型をネイティブにサポートするハードウェアのインスタンスはほとんどありません_t。これは、コンパイラ (またはライブラリ) がそれらの型をエミュレートする必要があることを意味します (おそらく、ハードウェアはサポートしています)。

さらに、実際には比較的少数のプログラマーが (たとえば) a を非常に必要としており、それを実行uint_least21_tするコンパイラーとライブラリーを購入するために現金を支払う意思があるプログラマーはさらに少数です。

したがって、状況の組み合わせがあります。コンパイラーまたはライブラリーのベンダー (委員会の議事で投票権を持っている) は、そのような型をエミュレートすることに利益がない限り (つまり、そのような機能を備えたコンパイラーまたはライブラリーにかなりのお金を払うことを申し出る多くの有料顧客)、熱狂的ではありません。さらに、そのようなタイプをサポートするためにコンパイラーやライブラリーを開発するコスト (工数など) に見合う価値があるとベンダーに納得させるのに十分な商業的または政治的影響力を持つそのような機能を使用することに関心を持つプログラマーは比較的少数です。

標準化委員会にとって最も抵抗の少ない方法は、いくつかのタイプのみを必須にすることです。結局のところ、ほとんどのプログラマーが必要としない機能よりも、標準に投票する重要な機能が多くあります。さらに少数のプログラマーは喜んでお金を払い、比較的少数のベンダーがわざわざ実装しようとはしません。

于 2015-11-02T11:03:17.360 に答える