সি ++ সতর্কতা: শূন্যের দ্বিগুণ

Question

মামলা 1:

#include <iostream>

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

এটি কোনও সতর্কতা এবং প্রিন্ট ছাড়াই সংকলন করে inf। ঠিক আছে, সি ++ বিভাগটি শূন্য দ্বারা পরিচালনা করতে পারে, ( এটি সরাসরি দেখুন )।

কিন্তু,

কেস 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;

Why does the compiler give a warning in the second case?

Is 0 != 0.0?

Edit:

#include <iostream>

int main()
{
    if(0 == 0.0)
        std::cout<<"Same"<<std::endl;
    else
        std::cout<<"Not same"<<std::endl;
}

output:

Same

Comments

I assume it takes zero as an integer in the second case and drops a warning, even if the calculation would be done using double later on (which I think should be the behaviour when d is a double).

— Qubit

It's a QoI issue, really. Neither the warning or the lack of a warning is something mandated by the C++ standard itself. Are you using GCC?

— StoryTeller - Unslander Monica

#650275 - gcc-4.6: Does only detect division by zero for int, not float - Debian Bug report logs

— user202729

@StoryTeller What is QoI? en.wikipedia.org/wiki/QoI ?

— user202729

With regards to your last question, "is 0 the same as 0.0?" The answer is the values are the same, but as you found out, that doesn't mean they're identical. Different types! Just like 'A' is not identical to 65.

— Mr Lister

Answer 1

Floating point division by zero is well defined by IEEE and gives infinity (either positive or negative according to the value of the numerator ^{(or NaN for ±0)} ).

For integers, there is no way to represent infinity and the language defines the operation to have undefined behaviour so the compiler helpfully tries to steer you clear from that path.

However in this case, since the numerator is a double, the divisor (0) should be promoted to a double too and there's no reason to give a warning here whilst not giving a warning for 0.0 so I think this is a compiler bug.

Comments

Both are floating point divisions though. In d/0, 0 is converted to the type of d.

Note that C++ is not required to use IEEE 754 (even though I never seen a compiler using a different standard)..

— Yksisarvinen

@hvd, good point, it that case this looks like a compiler bug

— Motti

I would agree that it should either warn in both cases, or not warn in both cases (depending on what the compiler's handling of floating division by zero is)

— M.M

Pretty sure that floating point division by zero is UB too - it's just that GCC implements it according to IEEE 754. They don't have to do that though.

— Martin Bonner supports Monica

Answer 2

In Standard C++, both cases are undefined behaviour. Anything may happen, including formatting your hard drive. You should not expect or rely on "return inf. Ok" or any other behaviour.

The compiler apparently decides to give a warning in one case and not the other, but this doesn't mean that one code is OK and one isn't. It is just a quirk of the compiler's generation of warnings.

From the C++17 standard [expr.mul]/4:

The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined.

Comments

Not true, in floating point arithmetic's division by zero is well defined.

— Motti

@Motti - If one limits themselves to the C++ standard alone, there are no such guarantees. The scope of this question is not well specified, to be frank.

— StoryTeller - Unslander Monica

@StoryTeller I'm pretty sure (though I haven't looked at the standard document itself for this) that if std::numeric_limits<T>::is_iec559 is true, then division by zero for T is not UB (and on most platforms it's true for double and float, although to be portable you'll need to explicitly check that with an if or if constexpr).

— Daniel H

@DanielH - "Reasonable" is actually quite subjective. If this question was tagged language-lawyer there would be a whole other (much smaller) set of reasonable assumptions.

— StoryTeller - Unslander Monica

@M.M Remember that it's exactly what you said, but nothing more: undefined doesn't mean no requirements are imposed, it means no requirements are imposed by the standard. I would argue that in this case, the fact that an implementation defines is_iec559 as true means that the implementation is documenting behaviour that the standard leaves undefined. It's just that this is one case where the implementation's documentation can be read programmatically. Not even the only one: the same applies to is_modulo for signed integer types.

Answer 3

My best guess to answer this particular question would be that compiler emits warning before performing conversion of int to double.

So, the steps would be like this:

1. Parse expression
2. Arithmetic operator /(T, T2), where T=double, T2=int.
3. Check that std::is_integral<T2>::value is true and b == 0 - this triggers warning.
4. Emit warning
5. Perform implicit conversion of T2 to double
6. Perform well defined division (since compiler decided to use IEEE 754).

This is of course speculation and is based on compiler-defined specifications. From standard point of view, we're dealing with possible Undefined Behaviours.

---

Please note that this is expected behaviour according to GCC documentation
(btw. it seems that this flag can't be used explicitly in GCC 8.1)

-Wdiv-by-zero
Warn about compile-time integer division by zero. This is default. To inhibit the warning messages, use -Wno-div-by-zero. Floating point division by zero is not warned about, as it can be a legitimate way of obtaining infinities and NaNs.

Comments

This is not how C++ compilers work. The compiler has to perform overload resolution on / to know that it's division. If the left hand side would have been a Foo object, and there would be a operator/(Foo, int), then it might not even be division. The compiler only knows it's division when it has chosen built-in / (double, double) using an implicit conversion of the right-hand side. But that means it is NOT doing a division by int(0), it's doing a division by double(0).

— MSalters

@MSalters Please see this. My knowledge about C++ is limited, but according to the reference operator /(double, int) is certainly acceptable. Then, it says conversion is performed before any other action, but GCC could squeeze in a quick check if T2 is integer type and b == 0 and emit a warning if so. Not sure if that's fully standard compliant, but compilers have full freedom in defining warning and when they should be triggered.

— Yksisarvinen

We're talking about the built-in operator here. That's a funny one. It's not actually a function, so you can't take its address. Therefore you can't determine if operator/(double,int) really exists. The compiler may for instance decide to optimize a/b for constant b by replacing it with a * (1/b). Of course, that means you are no longer calling operator/(double,double) at runtime but the faster operator*(double,double). But it's now the optimizer which trips over 1/0, the constant it would have to feed to operator*

— MSalters

@MSalters Generally floating point division cannot be replaced with multiplication, probably apart from exceptional cases, such as 2.

— user202729

@user202729: GCC does it even for integer division. Let that sink in for a moment. GCC replaces integer division with integer multiplication. Yes, that's possible, because GCC knows it's operating on a ring (numbers modulo 2^N)

— MSalters

Answer 4

I will not go into the UB / not UB debacle in this answer.

I just want to point that 0 and 0.0 are different despite 0 == 0.0 evaluating to true. 0 is an int literal and 0.0 is a double literal.

However in this case the end result is the same: d/0 is floating point division because d is double and so 0 is implicitly converted to double.

Comments

I don't see how this is relevant, given that the usual arithmetic conversions specify that dividing a double by an int means that the int is converted to double , and it is specified in the standard that 0 converts to 0.0 (conv.fpint/2)

— M.M

@M.M the OP wants to know if 0 is the same as 0.0

— bolov

The question says "Is 0 != 0.0 ?". OP never asks if they are "the same". Also it seems to me that the intent of the question is to do with whether d/0 can behave differently to d/0.0

— M.M

@M.M - The OP did ask. They aren't really showing decent SO netiquette with those constants edits.

— StoryTeller - Unslander Monica

Answer 5

I would argue that foo/0 and foo/0.0 are not the same. Namely, the resulting effect of the first (integer division or floating point division) is highly dependant on the type of foo, while the same is not true for the second (it will always be a floating point division).

Whether any of the two is UB is irrelevant. Quoting the standard:

Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

(Emphasis mine)

Consider the "suggest parentheses around assignment used as truth value" warning: The way to tell the compiler that you really want to use the result of an assignment is by being explicit, and adding parenthesis around the assignment. The resulting statement has the same effect, but it tells the compiler you know what you're doing. The same can be said about foo/0.0: Since you're explicitly telling the compiler "This is floating point division" by using 0.0 instead of 0, the compiler trusts you and will not issue a warning.

Comments

Both have to undergo the Usual arithmetic conversions to get them to a common type, which will leave both cases floating point division.

— Shafik Yaghmour

@ShafikYaghmour You missed the point in the answer. Note that I never mentioned what is the type of foo. That is intentional. Your assertion is only true in the case that foo is a floating point type.

— Cássio Renan

I did not, the compiler has type information and understand conversions, perhaps a text based static analyzer may be caught out by such things but the compiler should not.

— Shafik Yaghmour

My point is that yes, the compiler knows the usual arithmetic conversions, but it chooses not to issue a warning when the programmer is being explicit. The whole point is that this is probably not a bug, but instead it is intentional behavior.

— Cássio Renan

Then the documentation I pointed to is incorrect, since both cases are floating-point division. So either the documentation is wrong or the diagnostic has a bug.

— Shafik Yaghmour

Answer 6

This looks like a gcc bug, the documentation for -Wno-div-by-zero clearly says:

Do not warn about compile-time integer division by zero. Floating-point division by zero is not warned about, as it can be a legitimate way of obtaining infinities and NaNs.

and after Usual arithmetic conversions covered in [expr.arith.conv] both operands will be double:

Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions, which are defined as follows:

...

— Otherwise, if either operand is double, the other shall be converted to double.

and [expr.mul]:

The operands of * and / shall have arithmetic or unscoped enumeration type; the operands of % shall have integral or unscoped enumeration type. The usual arithmetic conversions are performed on the operands and determine the type of the result.

With respect to whether floating point divide by zero is undefined behavior and how different implementation deal with it seem my answer here. TL;DR; It looks like gcc conforms to Annex F wrt to floating point divide by zero, so undefined does not play a role here. The answer would be different for clang.

Answer 7

Floating point division by zero behaves differently than integer division by zero.

The IEEE floating point standard differentiates between +inf and -inf, while integers cannot store infinity. Integer division by zero result is undefined behaviour. Floating point division by zero is defined by the floating point standard and results in +inf or -inf.

Comments

This is true but it’s not clear how this is relevant to the question, since floating point division is performed in both cases. There’s no integer division in OP’s code.

— Konrad Rudolph