ケース1:
#include <iostream>
int main()
{
double d = 15.50;
std::cout<<(d/0.0)<<std::endl;
}
警告なしにコンパイルされ、inf
が出力されます。さて、C++はゼロによる除算を扱うことができます( それを見てください ).
しかし、
ケース2:
#include <iostream>
int main()
{
double d = 15.50;
std::cout<<(d/0)<<std::endl;
}
コンパイラは次の警告を表示します( 実際に動作している )。
warning: division by zero [-Wdiv-by-zero]
std::cout<<(d/0)<<std::endl;
2番目のケースでコンパイラが警告を出すのはなぜですか?
0 != 0.0
はありますか?
編集:
#include <iostream>
int main()
{
if(0 == 0.0)
std::cout<<"Same"<<std::endl;
else
std::cout<<"Not same"<<std::endl;
}
出力:
Same
ゼロによる浮動小数点除算は、 IEEEによって明確に定義されています そして無限大を与えます(分子の値に従って正または負のいずれか)。 (または±0の場合はNaN
) ).
整数の場合、無限大を表現する方法はなく、言語は 未定義の動作 を持つように操作を定義しているので、コンパイラはそのパスからユーザをクリアしようとします。
ただし、この場合、分子はdouble
なので、除数(0
)も倍精度に昇格する必要があり、ここで警告を出す理由はありませんが0.0
に対して警告を出さないので、これはコンパイラのバグであると思います。
標準C++では、どちらの場合も 未定義の動作 です。ハードドライブのフォーマットなど、何でも起こります。あなたは "return inf。Ok"や他の行動を期待したり頼りにしてはいけません。
コンパイラは、あるケースではなく他のケースで警告を出すことにしているようですが、これは1つのコードが問題ないことを意味するわけではありません。これは、コンパイラが生成する警告の奇妙な表現です。
C++ 17標準から[expr.mul]/4:
2進
/
演算子は商を生成し、2進%
演算子は最初の式を2番目の式で除算した余りを生成します。/
または%
の2番目のオペランドがゼロの場合、動作は未定義です
この特別な質問に答えるための私の最も良い推測は、コンパイラが警告を発するということです 前にint
からdouble
への変換の実行。
そのため、手順は次のようになります。
/(T, T2)
、ここでT=double
、T2=int
。std::is_integral<T2>::value
がtrue
およびb == 0
であることを確認してください - これは警告を引き起こします。T2
からdouble
への暗黙の変換を実行するこれは憶測であり、コンパイラ定義の仕様に基づいています。標準的な観点からは、可能な未定義の動作を扱っています。
これは GCCのドキュメント に従って予想される動作です。
(ところで、このフラグはGCC 8.1では明示的に使用できないようです)
-Wdiv-by-zero
コンパイル時のゼロによる整数除算について警告します。これはデフォルトです。警告メッセージを表示しないようにするには、-Wno-div-by-zeroを使用します。ゼロによる浮動小数点除算は、無限大およびNaNを取得するための正当な方法である可能性があるため、警告されません。
私はこの答えでUB/UBではない大惨事に陥らないでしょう。
0
がtrueと評価されているにもかかわらず、0.0
と0 == 0.0
が異なることを指摘したいだけです。 0
はint
リテラル、0.0
はdouble
リテラルです。
ただし、この場合、最終結果は同じです。d/0
は浮動小数点除算です。これは、d
がdoubleであり、したがって0
が暗黙的にdoubleに変換されるためです。
私はfoo/0
とfoo/0.0
は同じ{notであると主張します。つまり、最初の結果(整数除算または浮動小数点除算)の結果はfoo
の型に大きく依存しますが、2番目の結果も同じではありません(常に浮動小数点除算になります)。
どちらかがUBかどうかは関係ありません。標準を引用する:
許されている未定義の振る舞いは予測不可能な結果で状況を完全に無視することから環境に特有の文書化された方法で翻訳またはプログラム実行中に振る舞うまで(診断メッセージの発行ありまたはなし) _翻訳の終了までまたは(診断メッセージの発行を伴う)実行。
(私の強調)
「 真偽値として使用される代入を括弧で囲む 」という警告を考慮してください。あなたが本当にを使いたいことをコンパイラに伝える方法代入の結果は、明示的になり、代入の周りに括弧を追加することによって行われます。結果として得られるステートメントは同じ効果を持ちますが、コンパイラにあなたが何をしているのかを知らせます。 foo/0.0
についても同じことが言えます。0.0
の代わりに0
を使用してコンパイラに "これは浮動小数点除算である"と明示的に伝えているので、コンパイラはあなたを信頼し、警告を発行しません。
これはgccのバグのように見えます、-Wno-div-by-zero
のドキュメントには明らかに が書かれています。
コンパイル時のゼロによる整数除算について警告しないでください。 浮動小数点数の0による除算は、無限大およびNaNを取得するための正当な方法である可能性があるため、警告されません。
通常の算術変換後[expr.arith.conv] で囲まれている場合、両方のオペランドは次のようになります。double:
算術型または列挙型のオペランドを期待する多くの二項演算子でも、変換が行われ、同様に結果型が返されます。目的は、結果の型でもある共通の型を生成することです。このパターンは通常の算術変換と呼ばれ、次のように定義されています。
...
- それ以外の場合、どちらかのオペランドがdoubleの場合、もう一方はdoubleに変換されます。
and [expr.mul] :
*および/のオペランドは、算術またはスコープなしの列挙型になります。 %のオペランドは、整数型またはスコープなしの列挙型を持つものとします。 通常の算術変換がオペランドに対して実行され、結果のタイプが決まります。
浮動小数点をゼロで割ることが未定義の振る舞いであるかどうか、そして異なる実装がそれをどう扱うかということに関しては 私の答えはここ です。 TL; DR;gccは、Annex F wrtを浮動小数点のゼロ除算に準拠しているように見えます。このように未定義はここでは役割を果たしません。答えはclangによって異なります。
ゼロによる浮動小数点除算は、ゼロによる整数除算とは異なる動作をします。
IEEE浮動小数点 標準は+ infと-infを区別しますが、整数は無限大を格納できません。ゼロによる整数除算の結果は未定義の動作です。ゼロによる浮動小数点除算は、浮動小数点標準によって定義され、+ infまたは-infになります。