CおよびC ++で符号なし整数を使用する

長い間私を困惑させる非常に簡単な質問があります。私はネットワークとデータベースを扱っているので、扱うデータの多くは32ビットと64ビットのカウンター（符号なし）、32ビットと64ビットの識別IDです（また、符号の意味のあるマッピングはありません）。私は、負の数として表現される可能性のある実際の単語の問題を実際に扱うことは決してありません。

私と私の同僚は、これらの問題のためにuint32_t、通常、符号なしの型uint64_tを使用します。頻繁に発生するため、配列インデックスや他の一般的な整数の使用にも使用します。

同時に、私が読んでいるさまざまなコーディングガイド（Googleなど）は、符号なし整数型の使用を推奨しておらず、JavaとScalaのどちらにも符号なし整数型がないことを知っています。

ですから、私たちの環境で署名された値を使用するのは非常に不便であると同時に、コーディングガイドがまさにこれを行うことを主張する正しいことを理解できませんでした。

これについては2つの考え方があり、どちらも同意しません。

最初の例では、配列インデックスなど、本質的に符号なしの概念がいくつかあると主張しています。エラーが発生する可能性があるため、符号付きの数字を使用することは意味がありません。また、不必要な制限を課す可能性があります-符号付き32ビットインデックスを使用する配列は20億エントリにしかアクセスできませんが、符号なし32ビット番号に切り替えると40億エントリが許可されます。

2番目は、符号なしの数値を使用するプログラムでは、遅かれ早かれ、符号付きと符号なしの混合演算を行うことになります。これにより、奇妙で予期しない結果が生じる可能性があります。大きな符号なしの値を符号付きにキャストすると負の数値が得られ、逆に負の数を符号なしにキャストすると大きな正の数値が得られます。これはエラーの大きな原因になる可能性があります。

まず第一に、Google C ++コーディングガイドラインは従うにはあまり良いものではありません。現代のC ++の定番である例外やブーストなどを排除します。第二に、特定のガイドラインがX社に有効であるからといって、それがあなたにぴったりだというわけではありません。署名のないタイプの使用は引き続き必要です。

C ++の適切な経験則intは、他の何かを使用する正当な理由がない限り、好むということです。

他の答えには実世界の例がないため、1つ追加します。私が（個人的に）符号なしの型を避けようとする理由の1つ。

標準のsize_tを配列インデックスとして使用することを検討してください。

for (size_t i = 0; i < n; ++i)
    // do something here;

わかりました、完全に普通。次に、何らかの理由でループの方向を変更することにしたことを検討してください。

for (size_t i = n - 1; i >= 0; --i)
    // do something here;

そして今では機能しません。intイテレータとして使用した場合、問題はありません。過去2年間でこのようなエラーが2回発生しました。実稼働環境で発生し、デバッグが困難でした。

私のもう1つの理由は、毎回このようなことを書くようにする迷惑な警告です：

int n = 123;  // for some reason n is signed
...
for (size_t i = 0; i < size_t(n); ++i)

これらはマイナーなものですが、それらは合計します。どこでも符号付き整数のみが使用されている場合、コードはよりクリーンであると感じます。

編集： 確かに、例は馬鹿げているように見えますが、私は人々がこの間違いを犯しているのを見ました。それを避ける簡単な方法があれば、それを使ってみませんか？

VS2015またはGCCで次のコードをコンパイルすると、デフォルトの警告設定で警告が表示されません（GCCの-Wallを使用しても）。GCCでこれに関する警告を得るには、-Wextraを要求する必要があります。これは、常にWallとWextraでコンパイルする必要がある理由の1つです（そして静的アナライザーを使用します）が、多くの実際のプロジェクトではそうしません。

#include <vector>
#include <iostream>


void unsignedTest()
{
    std::vector<int> v{ 1, 2 };

    for (int i = v.size() - 1; i >= 0; --i)
        std::cout << v[i] << std::endl;

    for (size_t i = v.size() - 1; i >= 0; --i)
        std::cout << v[i] << std::endl;
}

int main()
{
    unsignedTest();
    return 0;
}

for (size_t i = v.size() - 1; i >= 0; --i)
   std::cout << v[i] << std::endl;

ここでの問題は、誤った動作を引き起こす巧妙な方法でループを記述したことです。ループの構築は、初心者が符号付きの型について教えられるようになっています（これはOKで正しいです）が、符号なしの値には適合しません。しかし、これは符号なしの型の使用に対する反論として機能することはできません。ここでのタスクは、単純にループを正しくすることです。そして、これは次のような署名されていない型で確実に動作するように簡単に修正できます：

for (size_t i = v.size(); i-- > 0; )
    std::cout << v[i] << std::endl;

この変更は単純に比較とデクリメント操作のシーケンスを元に戻し、私の意見では、バックワードループで符号なしカウンターを処理するための最も効果的で邪魔にならず、クリーンでショートな方法です。whileループを使用する場合、まったく同じことを（直感的に）行います。

size_t i = v.size();
while (i > 0)
{
    --i;
    std::cout << v[i] << std::endl;
}

アンダーフローは発生せず、空のコンテナの場合は、符号付きカウンターループのよく知られたバリアントのように暗黙的にカバーされ、ループの本体は符号付きカウンターまたはフォワードループと比較して変更されないままです。最初は少し奇妙に見えるループ構造に慣れる必要があります。しかし、それを数十回見た後、もはや理解できないものはありません。

初心者向けコースが、署名された型だけでなく、署名されていない型に対しても正しいループを表示するようになれば幸運です。これにより、署名のないタイプを非難する代わりに、知らないうちの開発者に非難されるべきいくつかのエラーを回避できます。

HTH

符号なし整数は理由があります。

たとえば、ネットワークパケットやファイルバッファなどの個別のバイトとしてデータを渡すことを検討してください。時折、24ビット整数のような獣に遭遇するかもしれません。3つの8ビット符号なし整数から簡単にビットシフトできますが、8ビット符号付き整数ではそれほど簡単ではありません。

または、文字参照テーブルを使用するアルゴリズムについて考えてください。文字が8ビットの符号なし整数である場合、文字値でルックアップテーブルにインデックスを付けることができます。ただし、プログラミング言語が符号なし整数をサポートしていない場合はどうしますか？配列に負のインデックスがあります。まあ、私はあなたがのようなものを使用できると思いますが、それはただいですcharval + 128。

実際、多くのファイル形式は符号なし整数を使用しており、アプリケーションプログラミング言語が符号なし整数をサポートしていない場合、問題になる可能性があります。

次に、TCPシーケンス番号を検討します。TCP処理コードを作成する場合は、符号なし整数を使用する必要があります。

場合によっては、効率が非常に重要になるため、余分なビットの符号なし整数が本当に必要になります。たとえば、数百万台で出荷されるIoTデバイスを検討してください。その後、多くのプログラミングリソースを、マイクロ最適化に費やすことを正当化できます。

符号なし整数型（混合符号演算、混合符号比較）の使用を避けるための正当化は、適切な警告を行うコンパイラーによって克服できると主張します。通常、このような警告はデフォルトでは有効になっていませんが、eg -Wextraまたはを個別に参照してください-Wsign-compare（-WextraCでは自動的に有効になりますが、C ++では自動的に有効になりませんが）-Wsign-conversion。

それでも、疑わしい場合は、署名されたタイプを使用してください。多くの場合、それはうまくいく選択です。そして、これらのコンパイラの警告を有効にしてください！

整数が実際に数値を表さない場合が多くありますが、たとえばビットマスク、idなどです。基本的に、整数に1を加算しても意味のない結果になる場合があります。これらの場合、符号なしを使用します。

整数を使用して算術演算を行う多くの場合があります。これらの場合、符号付き整数を使用して、ゼロ付近での誤動作を回避します。ループをゼロまで実行すると、非常に直感的でないコードを使用するか、符号なしの数値を使用しているために壊れる、ループの例を多数参照してください。「しかし、インデックスは決して負ではない」という議論があります-確かですが、たとえばインデックスの違いは負です。

インデックスが2 ^ 31を超えて2 ^ 32を超えない非常にまれなケースでは、符号なし整数を使用せず、64ビット整数を使用します。

最後に、良いトラップ：ループ内で「for（i = 0; i <n; ++ i）a [i] ...」 i = 2 ^ 32-1 iでラップアラウンドするため、ポインタをインクリメントすることによるa [i]へのアクセス。nがそれほど大きくならない場合でも。符号付き整数を使用すると、これを回避できます。

最後に、私はここで本当に良い答えを見つけました：J.ViegaとM.Messierによる「Secure Programming Cookbook」（http://shop.oreilly.com/product/9780596003944.do）

符号付き整数のセキュリティ問題：

1. 関数が正のパラメーターを必要とする場合、低い範囲のチェックを忘れがちです。
2. 負の整数サイズ変換からの直感的でないビットパターン。
3. 負の整数の右シフト演算によって生成される直感的でないビットパターン。

符号付き<->符号なし変換には問題があるため、mixを使用することはお勧めできません。