問題タブ [narrowing]
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++11 - gcc は、非型テンプレート引数の縮小変換を診断しないのは間違っていますか?
次のプログラムは、gcc 4.8.1 でエラーや警告なしにコンパイルされます
-Wall -std=c++11
。
同じオプションで clang 3.3 を実行すると、次のエラーが発生します。
エラー: 非型のテンプレート引数が -1 に評価され、型 'unsigned int' [-Wc++11-narrowing] に狭められません
この質問によると、標準がエラーを示し、clang が示されたエラーを示す場所で、変換を狭めるために警告を出すだけの gcc の現在のポリシーのように見えます。しかし、この場合、gcc は警告すら出ません。
§ 8.5.4/7 で標準によって与えられている縮小変換エラーの例 (その質問で再現) のいずれも、非型テンプレート引数の縮小変換のケースをカバーしていませんが、§ 14.3.2/5 では規格は次のように述べています。
整数型または列挙型の非型テンプレート パラメータの場合、変換された定数式 (5.19) で許可されている変換が適用されます。
§ 5.19/3 には次のように書かれています。
型 T の変換された定数式は、リテラル定数式であり、暗黙的に型 T に変換されます。暗黙的な変換 (存在する場合) はリテラル定数式で許可され、暗黙的な変換シーケンスには、ユーザー定義の変換 (左辺値から左辺値への変換) のみが含まれます。縮小変換(8.5.4)以外の右辺値変換 (4.1)、整数昇格 (4.5)、および整数変換 (4.7 )
(私の強調)。
これは、この場合、gcc 自体の尺度でさえ、縮小変換をまったく診断しないという点で誤りがあることを意味しているように私には思えます。私はこれを正しく読んでいますか?標準ベースの反論はありますか?
単なる好奇心よりも気持ちを込めて質問しています。再帰的な TMP 設定では、この場合の clang のエラー診断は、符号なしの非型テンプレート引数が 0 を通過するバグを特定しますが、gcc から得られるのは「テンプレートのインスタンス化の最大深度を超えました」だけです。
java - プリミティブ データ型に関するいくつかの質問
私はJavaを勉強していて、不明な点がいくつかあります。誰かが助けてくれればとてもうれしいです。
最初の質問
int の近似値は次のとおりです: 2.147.483,647
long の概算値: 9,223,372,036,854,775,807
このウェブサイトには次のように書かれています。
「整数リテラルは、文字 L または l で終わる場合は long 型であり、それ以外の場合は int 型です」
つまり、変数名の末尾に文字 L/l を追加していない場合
そのような :
そのため、変数は long 型ではなく型num
と見なされます。int
だから私はこのプログラムを作りました:
これは出力です:
int のおおよその値は : 2,147,483,647 で、変数 max は int です。太字の値はどのように出力されましたか?
2 番目の質問:
コンバージョンの絞り込みについて:
私の発言は本当ですか?
byte 型 (8 ビット) と short 型 (16 ビット) は、byte/short 型で見つかった値が次の値のいずれかである場合にのみ、char 型 (16 ビット) に変換できます: 0,1,2,3,4 ,5,6,7,8,9 そうしないと実行時エラーが発生します
- 3 番目と最後の質問 :
次のような数値変数型を宣言する場合:
文字が象徴する場合、最初の文字を使用する他の型で変数を宣言することもできますか? num1 から num2 と num3 から num4 の違いは何ですか?
c++ - 二重の誤解に浮かぶ?g++
何らかの理由で、次の警告が表示されます
これは、「float cos(float)」などの代わりに「double cos(double)」などを使用しようとしているように聞こえます。これをコンパイラに提案する方法をもっと考えようとしていますが、どこにも行きません。これを解決するにはどうすればよいですか?
ありがとう
編集:これに変更すると警告が消えますが、それでも問題が何であるかを知りたいです
c++ - なぜ `bool b = 2` はうまく動作するのに `bool b = {2}` は縮小変換の警告を出すのですか?
{}
で初期化子を使用して初期C++11
化bool b = {2}
すると、次の警告メッセージが表示されます。
ただし、古いスタイルを使用する場合bool b = 2
は、そのような問題はありません。この背後にある理由は何ですか?
更新: を使用してコードをコンパイルしたg++ -std=c++11
ところ、警告が表示されました。オプションを追加する-pedantic-errors
と、警告がエラーになります。
c++ - 以下の式が縮小変換を特徴付けるのはなぜですか?
この式は、標準 (N3797) の §8.5.4/7 の例に記載されています。
§8.5.4/7 とその 4 番目の箇条書きを考えると:
縮小変換は暗黙の変換です。
- 整数型またはスコープのない列挙型から、元の型のすべての値を表すことができない整数型へ。ただし、ソースが整数昇格後の値がターゲット型に適合する定数式である場合を除きます。
-1 は定数式であり、整数昇格後の値は unsigned int に収まるため、ここでは狭小化はないと思います。
Integral Promotionについては、§4.5/1 も参照してください。
bool、char16_t、char32_t、または wchar_t 以外の整数型の prvalue で、整数変換ランク (4.13) が int のランクよりも小さいものは、int がソース型のすべての値を表すことができる場合、int 型の prvalue に変換できます。 ; それ以外の場合は、ソースの prvalue を unsigned int 型の prvalue に変換できます。
4.13 から、-1 (int) のランクは unsigned int のランクに等しいため、unsigned int に変換できます。
編集
残念ながら、 Jerry Coffinはこのスレッドから回答を削除しました。この標準の変更後、§8.5.4/7 の 4 番目の箇条書きの現在の読み方が間違っているという事実を受け入れるならば、彼は正しい方向に進んでいたと思います。
c++ - 「int」から「double」への縮小変換と配列の初期化
以下
のエラー (clang の場合) または警告 (gcc の場合) を返しnarrowing conversion from 'int' to 'double'
ます。少なくともunsigned から double への縮小変換を見るまでは、これが本当に縮小していることは驚くべきことでした。
私の実際の問題は、配列を含むクラスから発生し、配列の要素を指定するためのコンストラクターを可能な限り簡単な方法 (転送) で提供します。
この場合、次のようになります ( live example )。
whereERROR
は、前述の縮小変換を指します。これらのエラーはすべて、最初に述べたもの ( double d{i};
) に集約されるのではないかと思います。そうですか?そうでなければ、何が起こっていますか?
とにかく、私は本当に欲しいです
まさに同じように働く
動作します。残念ながら、初期化リストを使用して配列を初期化することしかできません。これは、縮小変換もチェックします。回避策の 1 つは、コンストラクターで明示的なキャストを行うことです。
または(マークに感謝)
しかし、これは「正しい」方法ですか?E
そして、「大きな」タイプはいつ最も効率的ですか?
java - Javaでの型変換の縮小とは正確には何ですか?
Java での私の知識によると、型変換を絞り込む際に、ソースがバイトの範囲内にある定数の場合、次のものが許可されます。
しかし、これを入力すると:
なんでそうなの ?これらの縮小変換が Java で行われる正確な規則を教えてください。