私が取り組んでいるライブラリは、32ビットマシンと64ビットマシンの両方で使用する必要があります。64ビットマシンでは、コンパイラの警告がたくさんありますunsigned int != size_t。
unsigned intすべてのsとsize_tsを「unsignedlong」に置き換えることの欠点はありますか？あまりエレガントに見えないのはありがたいですが、場合によってはメモリはそれほど問題ではありません...そのようなreplace all操作によってバグや望ましくない動作などが発生する可能性があるのではないかと思います（よろしいですか？例を上げてください）？ありがとう。
どのような警告？私が考えることができる最も明白なものは、「変換を狭める」ことです。つまり、に割り当てsize_tてunsigned intいるので、情報が失われる可能性があるという警告が表示されます。
に置き換えることの主な欠点は、のすべての可能な値を含むのに十分な大きさが保証されていないことですsize_t。unsigned longまた、Windows64では十分な大きさではありません。したがって、まだ警告があることに気付くかもしれません。unsigned longsize_t
適切な修正はsize_t、変数（またはデータメンバー）にを割り当てる場合、変数がの値を含むのに十分な大きさの型を持っていることを確認する必要があるということですsize_t。それが警告のすべてです。したがって、に切り替えるのではなくunsigned long、これらの変数をに切り替える必要がありますsize_t。
逆に、任意のサイズを保持するのに十分な大きさである必要はなく、ちょうど十分な大きさの変数がある場合は、そもそもそれをunsigned int使用しないでくださいsize_t。
両方のタイプ（size_tおよびunsigned int）には有効な使用法があるため、それらのすべての使用法を他のタイプに無差別に置き換えるアプローチは間違っている必要があります:-)実際には、すべてを、またはほとんどのプログラムで問題なく置き換えることがsize_tできます。例外は、コードが、と同じサイズの符号なしタイプの使用などに依存しているため、より大きなタイプではコードが破損する場合です。uintmax_tint
intこの規格では、やのようなタイプのサイズについてはほとんど保証されていませんlong。size_tは、あらゆるオブジェクトを保持するのに十分な大きさであることが保証されており、すべてのstdコンテナはで動作しsize_tます。
たとえば、プラットフォームがlong、よりも小さいと定義したり、コンパイルオプションの対象となるsize_tサイズを設定したりすることは完全に可能です。long安全のために、に固執するのが最善size_tです。
考慮すべきもう1つの基準は、size_t「サイズまたはインデックスを格納するために使用される」という意味を持っていることです。これにより、コードが少し自己文書化されます。
を取得して置き換える必要size_tがある場所で使用している場合は、新しい警告が表示されます。size_tunsigned long
例：
size_t count = some_vector.size();
に置き換えsize_tてunsigned longください。（それらが異なる程度で）新しい警告が導入されます（実際には-がsome_vector.size()返されるためですが、実際には同じと評価されるはずです）。size_tstd:::vector<something>::size_type
longが8バイトの場合、unsignedlongであると想定するのは問題になる可能性があります。then（unsigned int）-1！=（unsigned long）-1、次のコードはアサーションに失敗する可能性があります。
unsigned int i = string::npos;
assert(i == string::npos);