問題タブ [unsigned]

Javaには、符号なしバイトなどはありません。

低レベルのコードを使用する場合、128を超える符号なしの値を持つバイトを処理する必要がある場合があります。これにより、Javaは、MSBが符号に使用されているため、それらを負の数として解釈します。

これを回避するための良い方法は何ですか？（Javaを使用しないと言うことはオプションではありません）

コンポーネントには、後でキーとしてキャッシュに使用する long 値が渡されます。キー自体は、符号なしの 64 ビット値であるかのように、long 値の文字列表現です。つまり、コンポーネントが -2944827264075010823L に渡された場合、それを文字列キー "15501916809634540793" に変換する必要があります。

解決策はありますが、力ずくのようで、少し吐き気がします。基本的に、long を 16 進数の文字列表現に変換し (つまり、-2944827264075010823L は "d721df34a7ec6cf9" になります)、16 進数の文字列を BigInteger に変換します。

次に、キャッシュへのキーとして longValueString を使用します。

Long.toString(longValue,16) は使用できません。これは、絶対値の 16 進文字列が返され、接頭辞が "-" になっているためです。

したがって、私の convertLongToHexString は次のようになります。

これを行うためのよりエレガントな方法が必要です。助言がありますか？

符号付き整数と符号なし整数の違いは次のとおりです。

1. 符号なしはより大きな正の値を保持でき、負の値は保持できません。
2. 符号なしは先頭ビットを値の一部として使用しますが、符号付きバージョンは左端のビットを使用して数値が正か負かを識別します。
3. 符号付き整数は、正と負の両方の数値を保持できます。

他に違いはありますか？

私自身、私が取り組んでいるプロジェクトでは、含まれる値が決して負になることはありませんが、ほとんどの場合、符号付き整数が最良の選択であると確信しています。(特に 0 から 20 の間の値しか保持できない整数の場合、ループの単純な逆、バグの可能性が少なくなります。)

これがうまくいかない場所の大部分は、std::vector の単純な繰り返しです。多くの場合、これは過去には配列でしたが、後で std::vector に変更されました。したがって、これらのループは一般的に次のようになります。

このパターンは非常に頻繁に使用されるため、符号付き型と符号なし型のこの比較に関するコンパイラ警告スパムの量によって、より有用な警告が隠される傾向があります。INT_MAX 要素を超えるベクトルは絶対にないことに注意してください。これまで、コンパイラの警告を修正するために 2 つの方法を使用していたことに注意してください。

これは通常は機能しますが、ループに「if (i-1 >= 0) ...」などのコードが含まれていると、黙って中断する可能性があります。

この変更には副作用はありませんが、ループが読みにくくなります。（そして、それはより多くのタイピングです。）

そこで、次のアイデアを思いつきました。

表示されるのは、基本的に、size_type をオーバーライドして「int」のみを返すメソッドを持つ STL クラスです。これらは継承されないため、コンストラクターが必要です。

既存のコードベースでこのようなソリューションが見られるとしたら、開発者としてこれをどう思いますか?

「うわあ、彼らは STL を再定義している、なんと巨大な WTF だ!」と思いますか?それとも、これはバグを防ぎ、読みやすさを向上させるための素晴らしいシンプルなソリューションだと思いますか? それとも、これらすべてのループを std::vector<>::iterator を使用するように変更するのに (半日) ほど費やしたことを知りたいですか?

(特に、この解決策が生データ (例: unsigned char) とビット マスク以外での unsigned 型の使用の禁止と組み合わされた場合。)

Cプログラムは、64ビットの符号なし整数と見なされるものを、int8と入力されたPostgresデータベースの列に配置します。Postgresにとって、int8は常に'signed int8'です（'unsigned int8'のようなものはありません）。したがって、私が持っているRubyプログラムは、そのスペースの上半分にあるPostgresから取得した数値を負として表示します。

Rubyで、その-ve整数を取得し、Cプログラマーが意図した64ビットの符号なし整数に変換する正しい方法は何ですか？

現在取り組んでいるコードでこれを見つけ、それが私が抱えているいくつかの問題の原因であると考えました。

どこかのヘッダーで：

その後 - 初期化:

そして使う

コードをデバッグすると、nextIndex の値が意味をなさない (非常に大きい) ため、次のように宣言されていることがわかりました。

そのため、INVALID_INDEX への初期設定は、unsigned int をアンダーフローして膨大な数に設定していました。それが問題の原因だと思いましたが、詳しく見ると、テスト

つまり、nextIndex が「大きな +ve 値」の場合、if の本体を実行しませんでした。

これは正しいです？これはどのように起こっていますか？enum 値は変数と同じ型の unsigned int に暗黙的にキャストされているため、同じようにラップされていますか?

私はかなり大きな数を使用するアプリケーションを使用しており、データを符号なし64ビット整数として格納する必要があります。さまざまなプログラムがさまざまな方法でデータを使用できるように、ビット操作などを気にせずに保存することを好みます。

私が C# でライブラリを作成していて、誰がそれを使用するのか分からないとしましょう。

ライブラリのパブリック インターフェイスには、uint、ushort などの符号なし型がいくつかあります。どうやらこれらの型は CLS に準拠しておらず、理論的に言えば、それらを使用できない言語が存在する可能性があります。

実際にそのような言語はありますか?

Python の Unicode 文字列を unsigned および signed int 8 ビット、unsigned および signed int 16 ビット、unsigned および signed int 32 ビット、unsigned および signed int 64 ビット、double、float、string、unsigned および signed などの他の型に変換する必要があります。 8 ビット、符号なしおよび符号付き 16 ビット、符号なしおよび符号付き 32 ビット、符号なしおよび符号付き 64 ビット。

私はあなたからの助けが必要です。

変数の型が符号なし 32 ビットか符号付き 16 ビットかなどを確認するにはどうすればよいですか?

どうすれば表示できますか?