C ++警告：ゼロによるdoubleの除算

ケース1：

#include <iostream>

int main()
{
    double d = 15.50;
    std::cout<<(d/0.0)<<std::endl;
}

警告なしでコンパイルして出力しinfます。OK、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によって明確に定義され、無限大を与えます（分子の値に応じて^{（またはNaN±0の場合）}正または負）。

整数の場合、無限を表す方法はなく、言語は動作を未定義の動作に定義しているため、コンパイラーはそのパスから離れるようにしています。

ただし、この場合、分子はa doubleであるため、除数（0）も2倍に昇格する必要があり、警告を出さずにここで警告を出す理由はない0.0ので、これはコンパイラのバグだと思います。

標準C ++では、どちらの場合も未定義の動作です。ハードドライブのフォーマットを含め、何が起こる可能性があります。「return inf。Ok」またはその他の動作を期待したり、これらに依存したりしないでください。

コンパイラは、ある場合に警告を出し、別の場合には警告を出さないようにしていますが、これは1つのコードに問題がないことを意味するわけではありません。これは、コンパイラーが生成する警告の癖です。

C ++ 17標準[expr.mul] / 4から：

二項/演算子は商を生成し、二項%演算子は最初の式を2番目の式で除算した余りを生成します。またはの2番目のオペランドがゼロの場合の動作は未定義です。/%

この特定の質問に答えるには、コンパイラがtoへの変換を実行する前に警告を発するのが私の推測です。intdouble

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

1. 解析式
2. 算術演算子 /(T, T2)、ここでT=double、T2=int。
3. チェックしstd::is_integral<T2>::valueているtrueとb == 0、このトリガーが警告- 。
4. 警告を出す
5. toを暗黙的に変換T2するdouble
6. 明確に定義された除算を実行します（コンパイラがIEEE 754を使用することを決定したため）。

これはもちろん推測であり、コンパイラ定義の仕様に基づいています。標準的な観点から、私たちは可能な未定義の振る舞いを扱っています。

これはGCCのドキュメントによると予想される動作であることに注意してください
（このフラグはGCC 8.1では明示的に使用できないようです）

-Wdiv-by-zero
コンパイル時のゼロによる整数除算について警告します。これがデフォルトです。警告メッセージを抑制するには、-Wno-div-by-zeroを使用します。ゼロによる浮動小数点除算は、無限大とNaNを取得する正当な方法となる可能性があるため、警告されません。

私はこの答えでUB / UBの失敗ではありません。

私はちょうどことを指すようにしたい0と0.0 異なっているにもかかわらず、0 == 0.0trueに評価します。0はintリテラルで0.0あり、doubleリテラルです。

ただし、この場合の最終結果は同じです。はdoubleであるためd/0、浮動小数点除算でdあり、0暗黙的にdoubleに変換されます。

私はそれを主張foo/0してfoo/0.0いるではない同じ。つまり、最初の結果（整数除算または浮動小数点除算）の効果は、のタイプに大きく依存しfooますが、2番目の場合は同じではありません（常に浮動小数点除算になります）。

2つのうちいずれかがUBであるかどうかは関係ありません。標準の引用：

許容される未定義の動作は、予測できない結果で完全に状況を無視することから、環境に特徴的な文書化された方法（診断メッセージの発行の有無にかかわらず）での動作またはプログラムの実行中、翻訳または実行の終了（発行あり）までさまざまです。診断メッセージの）。

（エンファシス鉱山）

「真偽値として使用される代入の前後に括弧を提案する」警告を考慮してください：代入の結果を本当に使用したいことをコンパイラーに伝える方法は、明示的で、代入の前後に括弧を追加することです。結果のステートメントは同じ効果がありますが、何をしているかをコンパイラーに知らせます。同じことが言えfoo/0.0ます：の0.0代わりにを使用してコンパイラに「これは浮動小数点除算です」と明示的に伝えているので0、コンパイラはあなたを信頼し、警告を発行しません。

これはgccのバグのように見え-Wno-div-by-zero ます。

コンパイル時のゼロによる整数除算について警告しません。ゼロによる浮動小数点除算は、無限大とNaNを取得する正当な方法となる可能性があるため、警告されません。

[expr.arith.conv]でカバーされる通常の算術変換の後、両方のオペランドはdoubleになります。

算術型または列挙型のオペランドを期待する多くの2項演算子は、変換を引き起こし、同様の方法で結果型を生成します。目的は、結果のタイプでもある一般的なタイプを生成することです。このパターンは通常の算術変換と呼ばれ、次のように定義されます。

...

— そうでない場合、一方のオペランドがdoubleの場合、もう一方はdoubleに変換されます。

および[expr.mul]：

*および/のオペランドは、算術型またはスコープ外の列挙型でなければなりません。％のオペランドは、整数型またはスコープ外の列挙型でなければなりません。 通常の算術変換はオペランドで実行され、結果のタイプを決定します。

浮動小数点のゼロ除算が未定義の動作であるかどうか、および異なる実装がそれをどのように処理するかに関しては、ここで私の答えのようです。TL; DR; gcc は、ゼロによる浮動小数点除算の付録Fに準拠しているように見えるため、未定義はここでは役割を果たしません。答えはclangでは異なります。

ゼロによる浮動小数点除算は、ゼロによる整数除算とは異なる動作をします。

IEEE浮動小数点 + INFと-INFの間の標準的な区別は、整数は無限大を格納することはできませんています。ゼロによる整数除算の結果は未定義の動作です。ゼロによる浮動小数点除算は、浮動小数点標準によって定義され、+ infまたは-infになります。