¿Por qué no hay ningún error del compilador cuando no está presente una declaración de devolución?

Question 1

A diferencia de Java, en C/C++ lo siguiente es permitió:

int* foo ()
{
  if(x)
    return p;

  // What if control reaches here?
}

Esto a menudo provoca bloqueos y es difícil depurar problemas. ¿Por qué el estándar obligar a tener un retorno final para no-void funciones? (Los compiladores generan un error por un error return valor.)

¿Hay una bandera en GCC o MSVC para hacer cumplir esto? (algo como -Wunused-result)

Question 2

No está permitido (comportamiento indefinido). Sin embargo, la norma no exige un diagnóstico en este caso.

El estándar no requiere que la última declaración sea return debido a un código como este:

while (true) {
  if (condition) return 0;
}

Esto siempre devuelve 0, pero un compilador tonto no puede verlo. Tenga en cuenta que el estándar no exige compiladores inteligentes. A return declaración después de la while block sería un desperdicio que un compilador tonto no podría optimizar. El estándar no quiere exigir que el programador escriba código de desecho solo para satisfacer a un compilador tonto.

g++ -Wall es lo suficientemente inteligente como para emitir un diagnóstico en mi máquina.

Question 3

Utilizar el -Muro bandera en CCG.

advertencia: el control llega al final de la función no nula

O más específicamente, -Tipo de retorno.

Question 4

Mi suposición: porque a veces el programador sabe más que el compilador. Con este simple ejemplo, está claro que algo está mal, pero considere un cambio de muchos valores o muchas comprobaciones en general. Tú, como codificador, saber que ciertos valores simplemente no se pasarán a la función, pero el compilador no lo hace y simplemente le indica que podría haber algo mal.

#include <iostream>

int foo(){
    if(false)
        return 5;
}

int main(){
    int i = foo();
    std::cout << i;
}

Tenga en cuenta que incluso nivel de advertencia 1 en MSVC da la siguiente advertencia:

advertencia C4715: ‘foo’: no todas las rutas de control devuelven un valor

Question 5

Puede convertir la advertencia en un error utilizando las siguientes opciones del compilador

-Wreturn-type -Werror=return-type.

Mira esto Enlace

Question 6

La respuesta obvia es: porque no es un error. Solo es un error si
x es falso y si la persona que llama usa el valor de retorno, ninguno de los cuales necesariamente puede ser determinado por el compilador, al menos en el caso general.

En este caso particular (devolviendo un puntero), no sería demasiado difícil requerir un return por todos los caminos; Java hace esto. En general, sin embargo, no es razonable en C++ requerir esto, ya que en C++, puede devolver tipos definidos por el usuario para los que puede ser imposible construir un valor (sin constructor predeterminado, etc.). Así que tenemos la situación en la que el programador podría no ser capaz de proporcionar un return
en una rama que sabe que no se puede tomar, y el compilador no puede determinar que la rama no se puede tomar.

La mayoría de los compiladores advertirán en tales casos, cuando pueda determinar el flujo. Sin embargo, todos los que he visto también advierten en algunos casos en los que es claramente imposible caerse del final. (Tanto g++ como VC++ advierten sobre:

int
bar( char ch )
{
    switch ( ch & 0xC0 ) {
    case 0x00:
    case 0x40:
        return 0;

    case 0x80:
        return -1;

    case 0xC0:
        return 1;
    }
}

, al menos con las opciones habituales. Aunque está bastante claro que esta función nunca se cae al final).

Question 7

Por lo que recuerdo, Visual Studio 2008 le advierte sobre una “ruta de ejecución que no tiene un valor de retorno”. Está permitido en el sentido de que “C++ no impedirá que te dispare en el pie”. Entonces debes pensar, no el compilador.

Question 8

Lo que dice el estándar sobre este tipo de programación es que produce comportamiento indefinido.

El comportamiento indefinido es la alegría y la lástima de C/C++, pero también es una característica fundamental del diseño del lenguaje que permite muchas de las optimizaciones de bajo nivel que hacen de C una especie de “ensamblador de alto nivel” (en realidad, no lo es). , pero solo para darte una idea).

Entonces, al redirigir a la respuesta de John sobre el cambio para usar con GCC, para saber “por qué” el estándar no lo impide, señalaría un análisis muy interesante del comportamiento indefinido y todos sus misterios: Lo que todo programador de C debe saber sobre el comportamiento indefinido. Es una lectura muy instructiva.

¿Ha sido útil esta solución?