私の理解では、 size_t と wchar_t の表現は完全にプラットフォーム/コンパイラ固有です。たとえば、Linux の wchar_t は現在通常 32 ビットですが、Windows では 16 ビットであると読みました。両方のプラットフォームで既存の標準 C ライブラリおよび関数との下位互換性を維持しながら、独自のコードでこれらを設定サイズ (int、long など) に標準化する方法はありますか?
私の目標は、本質的に、それらが設定されたサイズになるように typedef のようなことをすることです。これは何かを壊すことなく可能ですか？これを行う必要がありますか？より良い方法はありますか？
更新:これを行いたい理由は、文字列のエンコードが Windows と Linux の両方で一貫しているためです。
ありがとう！
C99 と C++0x の<stdint.h>/<cstdint>ヘッダーを探しているようですね。これはuint8_t、 、 などの型を定義しますint64_t。
cstdint.hppこれらのヘッダーがない場合は、Boost を使用できます。
これらの型を再定義したくありません。代わりに、C 標準ライブラリの一部であるint32_tor int16_t(符号付き 32 ビットおよび 16 ビット) のような typedef を使用できます。<stdint.h>
C++ を使用している場合、C++0x は、UTF-16 および UTF-32 を対象とした新しい型 (整数型の typedef だけではない) であるchar16_tandを追加します。char32_t
の場合、代わりに、プラットフォームに依存しない方法で Unicode を実装するICUwchar_tのようなライブラリを使用するだけです。次に、常に UTF-16 になるタイプを使用できます。エンディアンに注意する必要があります。ICU は、UChar (UTF-16) との間のコンバーターも提供します。UChar
いいえ。 typedef を使用して文字型を「修正」しようとする際の根本的な問題は、一部のプラットフォームでは組み込み関数およびワイド文字リテラルと一貫性があり、他のプラットフォームでは一貫していないものになってしまうことです。
すべてのプラットフォームで同じ文字列形式が必要な場合は、サイズと署名を選択するだけです。符号なしの 8 ビットの「文字」または符号付きの 64 ビットの「文字」が必要ですか? 適切なサイズの整数型を持つ任意のプラットフォームでそれらを使用できます (すべてではありません)。しかし、言語に関する限り、それらは実際には文字ではないため、それらに対して or を呼び出すことができる、またはリテラルの適切な構文があるとは期待しないstrlenでwcslenください。文字列リテラルは (変換すると) achar*であり、 asigned char*または anではありませんunsigned char*。ワイド文字列リテラルは であり、wchar_t*他の整数型と同等ですが、必ずしも希望するものとは限りません。
したがって、エンコーディングを選択し、それを内部で使用し、必要な文字列関数の独自のバージョンを定義して実装し、必要に応じて、文字列を受け取る非文字列関数のプラットフォームのエンコーディングとの間で変換する必要があります。utf-8 は適切なオプションです。C 文字列関数のほとんどは、完全に正しくなくてもかなり有用なことを行うという意味で、まだ「機能する」ためです。
wchar_t は、おそらく size_t よりもスティッキーなウィケットになるでしょう。size_t の最大サイズ (たとえば 8 バイト) を想定し、ファイル (またはソケット) に書き込む前にすべての変数をそれにキャストすることができます。心に留めておくべきもう1つのことは、何らかのバイナリ表現を読み書きしようとすると、バイト順序の問題が発生することです。とにかく、 wchar_t は、あるシステムでは utf-32 エンコーディングを表す場合があり (Linux がこれを行うと思います)、別のシステムでは UTF-16 エンコーディングを表す場合があります (Windows はこれを行います)。プラットフォーム間の標準フォーマットを作成しようとしている場合は、これらの問題をすべて解決する必要があります。
内部で UTF-8 を使用し、UTF-16 を必要とする Windows 関数に引数を渡すときにジャストインタイムで UTF-16 に変換します。UTF-32 はおそらく必要ありません。通常、文字列ではなく個々の文字を処理するのは (Unicode の意味で) 間違っているため、UTF-8 文字列を大文字にしたり正規化したりすることは、UTF-32 文字列よりも難しくありません。