Advertencia de C ++: división de doble por cero

Caso 1:

#include <iostream>

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

Se compila sin advertencias ni se imprime inf. Bien, C ++ puede manejar la división por cero ( véalo en vivo ).

Pero,

Caso 2:

#include <iostream>

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

El compilador da la siguiente advertencia ( véalo en vivo ):

warning: division by zero [-Wdiv-by-zero]
     std::cout<<(d/0)<<std::endl;

¿Por qué el compilador da una advertencia en el segundo caso?

Es 0 != 0.0?

Editar:

#include <iostream>

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

salida:

Same

La división de coma flotante por cero está bien definida por IEEE y da infinito (ya sea positivo o negativo según el valor del numerador ^{(o NaNpara ± 0)} ).

Para los números enteros, no hay forma de representar el infinito y el lenguaje define la operación para que tenga un comportamiento indefinido, por lo que el compilador intenta ayudarlo a alejarse de esa ruta.

Sin embargo, en este caso, dado que el numerador es a double, el divisor ( 0) también debe promoverse a un doble y no hay razón para dar una advertencia aquí sin dar una advertencia, 0.0así que creo que esto es un error del compilador.

En Standard C ++, ambos casos son comportamientos indefinidos . Puede suceder cualquier cosa, incluido el formateo de su disco duro. No debe esperar o confiar en "return inf. Ok" o cualquier otro comportamiento.

El compilador aparentemente decide dar una advertencia en un caso y no en el otro, pero esto no significa que un código esté bien y el otro no. Es solo una peculiaridad de la generación de advertencias del compilador.

Desde el estándar C ++ 17 [expr.mul] / 4:

El /operador binario produce el cociente y el %operador binario produce el resto de la división de la primera expresión por la segunda. Si el segundo operando de /o %es cero, el comportamiento no está definido.

Mi mejor suposición para responder a esta pregunta en particular sería que el compilador emite una advertencia antes de realizar la conversión de inta double.

Entonces, los pasos serían así:

1. Parse expresión
2. Operador aritmético /(T, T2) , donde T=double, T2=int.
3. Compruebe que std::is_integral<T2>::valuees truey b == 0- esto activa una advertencia.
4. Emitir advertencia
5. Realizar conversión implícita de T2adouble
6. Realice una división bien definida (ya que el compilador decidió usar IEEE 754).

Por supuesto, esto es especulación y se basa en especificaciones definidas por el compilador. Desde el punto de vista estándar, estamos tratando con posibles comportamientos indefinidos.

Tenga en cuenta que este es el comportamiento esperado de acuerdo con la documentación de GCC
(por cierto, parece que esta bandera no se puede usar explícitamente en GCC 8.1)

-Wdiv-by-zero
Advierte sobre la división de enteros en tiempo de compilación por cero. Esto es predeterminado. Para inhibir los mensajes de advertencia, use -Wno-div-by-zero. No se advierte sobre la división de coma flotante por cero, ya que puede ser una forma legítima de obtener infinitos y NaN.

No entraré en la debacle UB / no UB en esta respuesta.

Solo quiero señalar eso 0y 0.0 somos diferentes a pesar de 0 == 0.0evaluarlos como verdaderos. 0es un intliteral y 0.0es un doubleliteral.

Sin embargo, en este caso, el resultado final es el mismo: d/0es una división de punto flotante porque des doble y, por 0lo tanto, se convierte implícitamente en doble.

Yo diría que foo/0y nofoo/0.0 son lo mismo. Es decir, el efecto resultante de la primera (división de enteros o división de punto flotante) depende en gran medida del tipo de foo, mientras que no ocurre lo mismo con la segunda (siempre será una división de punto flotante).

Si alguno de los dos es UB es irrelevante. Citando el estándar:

El comportamiento indefinido admisible va desde ignorar la situación por completo con resultados impredecibles, hasta comportarse durante la traducción o ejecución del programa de manera documentada característica del entorno (con o sin la emisión de un mensaje de diagnóstico) , hasta terminar una traducción o ejecución (con la emisión de un mensaje de diagnóstico).

(El énfasis es mío)

Considere la advertencia " Sugerir paréntesis alrededor de la asignación usada como valor de verdad ": la forma de decirle al compilador que realmente desea usar el resultado de una asignación es ser explícito y agregar paréntesis alrededor de la asignación. La declaración resultante tiene el mismo efecto, pero le dice al compilador que sabe lo que está haciendo. Se puede decir lo mismo sobre foo/0.0: Ya que le está diciendo explícitamente al compilador "Esta es una división de punto flotante" usando en 0.0lugar de 0, el compilador confía en usted y no emitirá una advertencia.

Esto parece un error de gcc, la documentación -Wno-div-by-zero dice claramente :

No advierta sobre la división de enteros en tiempo de compilación por cero. No se advierte sobre la división en coma flotante por cero, ya que puede ser una forma legítima de obtener infinitos y NaN.

y después de las conversiones aritméticas habituales cubiertas en [expr.arith.conv] ambos operandos serán dobles :

Muchos operadores binarios que esperan operandos de tipo aritmético o enumeración provocan conversiones y producen tipos de resultados de forma similar. El propósito es producir un tipo común, que también es el tipo de resultado. Este patrón se denomina conversiones aritméticas habituales, que se definen de la siguiente manera:

...

- De lo contrario, si alguno de los operandos es doble, el otro se convertirá en doble.

y [expr.mul] :

Los operandos de * y / deberán tener un tipo de enumeración aritmético o sin ámbito; los operandos de% deberán tener un tipo de enumeración integral o sin ámbito. Las conversiones aritméticas habituales se realizan en los operandos y determinan el tipo de resultado.

Con respecto a si el punto flotante dividir por cero es un comportamiento indefinido y cómo lo maneja la implementación diferente, parece mi respuesta aquí . TL; DR; Parece que gcc se ajusta al Anexo F wrt para dividir el punto flotante por cero, por lo que undefined no juega un papel aquí. La respuesta sería diferente para clang.

La división de coma flotante por cero se comporta de manera diferente a la división entera por cero.

El estándar de coma flotante IEEE diferencia entre + inf y -inf, mientras que los enteros no pueden almacenar infinito. La división de enteros por resultado cero es un comportamiento indefinido. La división de coma flotante por cero está definida por el estándar de coma flotante y da como resultado + inf o -inf.