問題タブ [integer-promotion]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c - signed char を unsigned として読み取る - 型プロモーション
この小さなプログラムを考えてみましょう:
その出力は-1
、予想どおりです(char
システムで署名されていると考えてください)。私がやろうとしているのは、それを印刷すること255
です。もちろん、これは実際の状況を単純化したものであり、
c
署名されていないと定義することはできません。
最初に考えられる変更は%u
、代わりに as formatter を使用することですが、ここでは通常のタイプ プロモーション ルールが適用され、数値は 2 32 - 1 として出力されます。
では、int に昇格する前に、signed char を unsigned として読み取る方法はありますか? のアドレスに設定された unsigned char へのポインターを作成し、c
後で逆参照することはできますが、これが最善の方法であるかどうかはわかりません。
c - Cでのタイププロモーション
私は次のコードでかなり混乱しています:
それは戻ります:
式(a --b)のタイプはuint32_tのようです。両方の演算子がuint16_tであるため、理由がわかりません。
誰かが私にこれを説明できますか?
c - Cでの通常の算術変換:この特定のルールの背後にある理論的根拠は何ですか
k&RCから
- まず、一方のオペランドがlong doubleの場合、もう一方はlongdoubleに変換されます。
- それ以外の場合、一方のオペランドがdoubleの場合、もう一方はdoubleに変換されます。
- それ以外の場合、一方のオペランドがfloatの場合、もう一方はfloatに変換されます。
- それ以外の場合、積分昇格は両方のオペランドで実行されます。..。
これは以下の表現を意味します
実際には次のように計算されます
このルールの背後にある理論的根拠は何ですか?
これらの変換は、a、b、およびcが短い場合に発生しますか?
haskell - `Int8` のような低ビットサイズの整数型の使用とその目的
最近、すべての計算サイクルが、ほとんどの最新のプロセッサと OS で 32 ビットまたは 64 ビットのマシン語で実行されることを知りました。Int16
では、 、Int8
、 のような小さなビットサイズの値を使用する利点は何Word8
ですか? 彼らは正確には何のためにいるのですか?ストレージ削減のみですか?
いくつかのモジュールで構成されているが、値を返す単一の関数のみによってインターフェースされている複雑な計算プログラムを作成しているWord64
ため、プログラム全体がWord64
値になります。この質問への回答に興味があります。このプログラム内で、や などのさまざまIntegral
なタイプを使用して小さなエンティティを表現していることに気づき、それらが頻繁に変換されるのを見て、次のように考えました。私が知らず知らずのうちに盲目的に惹かれたそれらのタイプの正確な利点は何でしたか? 他の整数型を利用して最終的にそれらを変換することはまったく意味がありましたか、それともどこでも使用する必要があったのでしょうか?Word16
Word8
fromIntegral
fromIntegral
Word64
c - MISRA C:2004、ビットシフトによるエラー
MISRA C:2004 チェックをオンにして IAR Workbench コンパイラを使用しています。
フラグメントは次のとおりです。
MISRA エラーは次のとおりです。 エラー [Pm136]: 基礎となる MISRA 型 "unsigned char" から "unsigned int" への不正な明示的変換 (MISRA C 2004 ルール 10.3)
unsigned char
上記のコードには何も表示されません。
なぜミスラはここでエラーをスローしたのですか?での議論 左シフトとは異なる昇格規則を持つ可能性のある乗算について説明します。
私の理解では、コンパイラは式を小さいサイズに降格するのではなく、より大きなサイズのデータ型に昇格させる必要があります。
ここで実際に何が起こっているのですか?
コードを MISRA C:2004 に準拠させるにはどうすればよいですか?
編集1:
エラー行を次のように変更します。
エラーが消えません。
c - マシン上の int データ型の幅
int データ型の幅は、ALU のデータ幅に依存するというのは正しいですか? たとえば、32 ビット プロセッサが 32 ビット幅の int データ型を持つと言うのは正しいですか? 16 ビットと 8 ビットの場合も同様です (C では int のサイズが少なくとも16 ビットより大きいことが保証されていることに注意してください)。
c - インテグラルプロモーション
整数の昇格に関して、符号付き整数が元の型のすべての値を表すことができないのはいつですか?
テキスト K&R、C プログラミング言語、第 2 版より。p。174
A.6.1 インテグラル昇格
文字、short 整数、または整数ビットフィールド (すべて符号付きかどうかに関係なく)、または列挙型のオブジェクトは、整数が使用できる式で使用できます。int が元の型のすべての値を表すことができる場合、値は int に変換されます。それ以外の場合、値は unsigned int に変換されます。このプロセスは統合プロモーションと呼ばれます。
このコードは、私のシステムのタイプの制限を示しています。
結果は次のとおりです。
signed int 型は他のどの型よりもはるかに大きいので、いつ UINT_MAX にフォールバックするのでしょうか?
gcc - GCC、奇妙な整数拡張スキーム
私はGCCv4.4.5を使用していますが、予期していなかったデフォルトの整数拡張スキームに気づきました。
暗黙のバグを防ぐのに十分な警告をアクティブにするために、オプション-Wconversionをアクティブにしました。それ以降、以下のコードを実行すると、「「int」から「shortint」に変換すると値が変わる可能性があります」という警告が表示されます。
これは、「sB + sC」がintにプロモートされてから、shortで署名されたsAに割り当てられることを意味します。この警告を修正するには、このようにキャストする必要があります。
この警告は、以下のコードにも含まれています。
そして、これによって演算子+=を削除することで修正できます...
これは少し厄介な原因です。演算子+=、-=を使用できません。
GCCがオペランドに応じて正しい汎整数拡張を選択することを期待していました。つまり、sA = sB+sCとsA+= 5はすべてshortで署名されているため、 intに昇格しないでください。
デフォルトでintにプロモートするとオーバーフローのバグが防止されることは理解していますが、コードのほとんどをキャストするか、変数をintに変更する必要があるため、少し面倒です。
この整数拡張スキームを提示するために使用できるGCCオプションはありますか?
ご協力いただきありがとうございます。
c - 演算子 << による整数昇格
質問Bitshift と整数の昇格に似ていますか? 、左ビットシフトを使用する場合の整数昇格について質問があります。
この場合、value8 は最初に unsiged int にプロモートされますか、それとも実装固有ですか?
6.5.7 ビット単位のシフト演算子... 3 セマティクス ...
整数昇格は各オペランドで実行されます。結果の型は、昇格された左オペランドの型です。右オペランドの値が負の値であるか、プロモートされた左オペランドの幅以上である場合、動作は未定義です。
「整数の昇格は各オペランドで実行されます」と書かれています。、しかし、ここで昇格ルールは何ですか?
あるべきだとconvert to int if lesser rank than int
思いますが、見つかりません。
1 つのコンパイラ (Renesas nc30wa) は int に昇格しないので、これを尋ねます。そのため、私のサンプルでは結果は常に 0 です。
このプラットフォームでは、char は幅 8 ビット、int は 16 ビットです。
c++ - 単項マイナスが汎整数拡張を実行するのはなぜですか?
Tはテンプレート引数でありshort
、この場合はaです。単項マイナスは、明らかに汎整数拡張を実行します。
- 単項マイナスが汎整数拡張を実行するのはなぜですか?
auto
がに変更された場合T
、警告は生成されませんが、intをshortに割り当てる必要があります。警告がないのはなぜですか(VSが派手である可能性があります)?