¿Qué debería main () devolver en C y C ++?

¿Cuál es la forma correcta (más eficiente) de definir la función main() en C y C ++ – int main() o void main() – y por qué? Si int main() entonces return 1 o return 0 ?


Existen numerosos duplicados de esta pregunta, que incluyen:

  • ¿Cuáles son las firmas válidas para la función main() C?
  • El tipo de retorno de la función main()
  • Diferencia entre void main() e int main() ?
  • la firma main() en C ++
  • ¿Cuál es la statement correcta de main() ? – Para C ++, con una muy buena respuesta de hecho.
  • Estilos de funciones main() en C
  • Tipo de devolución del método main() en C
  • int main() vs void main() en C

Relacionado:

  • C ++ – int main(int argc, char **argv)
  • C ++ – int main(int argc, char *argv[])
  • ¿Es char *envp[] como tercer argumento para main() portable?
  • ¿Debe la función int main() devolver un valor en todos los comstackdores?
  • ¿Por qué el usuario debe definir el tipo de la función main() en C y C ++?
  • ¿Por qué int main(){} comstack?
  • ¿Definiciones legales de main() en C ++ 14?

    El valor de retorno para main debe indicar cómo salió el progtwig. La salida normal generalmente se representa con un valor de retorno 0 desde main . La terminación anormal generalmente se señala mediante un retorno distinto de cero, pero no existe un estándar para la interpretación de códigos que no sean cero. Además, como han señalado otros, void main() está explícitamente prohibido por el estándar de C ++ y no debe utilizarse. Las firmas main válidas de C ++ son:

     int main() 

    y

     int main(int argc, char* argv[]) 

    que es equivalente a

     int main(int argc, char** argv) 

    También vale la pena señalar que en C ++, int main() puede dejarse sin un valor de retorno, en cuyo punto se establece por defecto el retorno 0. Esto también es cierto con un progtwig C99. Si el retorno 0 debe omitirse o no está abierto al debate. El rango de firmas principales válidas del progtwig C es mucho mayor.

    Además, la eficiencia no es un problema con la función main . Solo se puede ingresar y dejar una vez (marcando el inicio y la terminación del progtwig) de acuerdo con el estándar de C ++. Para C, el caso es diferente y se permite reingresar a main() , pero probablemente debería evitarse.

    La respuesta aceptada parece estar dirigida a C ++, así que pensé que agregaría una respuesta que pertenece a C, y esto difiere de varias maneras.

    ISO / IEC 9899: 1989 (C90):

    main() debe declararse como:

     int main(void) int main(int argc, char **argv) 

    O equivalente. Por ejemplo, int main(int argc, char *argv[]) es equivalente a la segunda. Además, el tipo de retorno int puede omitirse ya que es un valor predeterminado.

    Si una implementación lo permite, main() puede declararse de otras maneras, pero esto hace que la implementación del progtwig se defina y deje de ser estrictamente conforme.

    La norma define 3 valores para la devolución que son estrictamente conformes (es decir, no se basa en el comportamiento definido por la implementación): 0 y EXIT_SUCCESS para una finalización exitosa, y EXIT_FAILURE para una terminación EXIT_FAILURE . Cualquier otro valor no es estándar y la implementación está definida. main() debe tener una statement de return explícita al final para evitar un comportamiento indefinido.

    Por último, no hay nada de malo desde el punto de vista de las normas al llamar a main() desde un progtwig.

    ISO / IEC 9899: 1999 (C99):

    Para C99, todo es igual que el anterior excepto que:

    • El tipo de retorno int no se puede omitir.
    • Puede omitir la statement de devolución de main() . Si lo haces, y main() finalizado, hay un return 0 implícito return 0 .

    Estándar C – Entorno hospedado

    Para un entorno alojado (ese es el normal), el estándar C11 (ISO / IEC 9899: 2011) dice:

    5.1.2.2.1 Inicio del progtwig

    La función llamada al inicio del progtwig se llama main . La implementación no declara ningún prototipo para esta función. Se definirá con un tipo de retorno de int y sin parámetros:

     int main(void) { /* ... */ } 

    o con dos parámetros (a los que se hace referencia aquí como argc y argv , aunque se pueden usar los nombres, ya que son locales para la función en la que se declaran):

     int main(int argc, char *argv[]) { /* ... */ } 

    o equivalente; 10) o de alguna otra manera definida por la implementación.

    Si se declaran, los parámetros de la función principal obedecerán las siguientes restricciones:

    • El valor de argc debe ser no negativo.
    • argv[argc] será un puntero nulo.
    • Si el valor de argc es mayor que cero, los miembros de la matriz argv[0] a argv[argc-1] inclusive contendrán punteros a las cadenas, que reciben los valores definidos por la implementación por el entorno de host antes del inicio del progtwig. La intención es suministrar a la información del progtwig determinada antes del inicio del progtwig desde otro lugar en el entorno alojado. Si el entorno de host no es capaz de suministrar cadenas con letras en mayúsculas y minúsculas, la implementación se asegurará de que las cadenas se reciban en minúsculas.
    • Si el valor de argc es mayor que cero, la cadena apuntada por argv[0] representa el nombre del progtwig; argv[0][0] será el carácter nulo si el nombre del progtwig no está disponible desde el entorno host. Si el valor de argc es mayor que uno, las cadenas apuntadas por argv[1] a argv[argc-1] representan los parámetros del progtwig.
    • Los parámetros argc y argv y las cadenas apuntadas por la matriz argv serán modificables por el progtwig y conservarán sus últimos valores almacenados entre el inicio del progtwig y la terminación del progtwig.

    10) Por lo tanto, int puede ser reemplazado por un nombre typedef definido como int , o el tipo de argv puede escribirse como char **argv , y así sucesivamente.

    Terminación del progtwig en C99 o C11

    El valor devuelto por main() se transmite al ‘entorno’ de una manera definida por la implementación.

    5.1.2.2.3 Terminación del progtwig

    1 Si el tipo de retorno de la función main es un tipo compatible con int , un retorno desde la llamada inicial a la función main equivale a llamar a la función de exit con el valor devuelto por la función main como argumento; 11) llegando a } que finaliza la función main devuelve un valor de 0. Si el tipo de devolución no es compatible con int , el estado de terminación devuelto al entorno de host no está especificado.

    11) De acuerdo con 6.2.4, la duración de los objetos con duración de almacenamiento automático declarada en main habrá finalizado en el primer caso, incluso cuando no lo hubieran tenido en el segundo.

    Tenga en cuenta que 0 tiene el mandato de ‘éxito’. Puede usar EXIT_FAILURE y EXIT_SUCCESS de si lo prefiere, pero 0 está bien establecido, y también lo es 1. Consulte también Códigos de salida mayores que 255 – ¿posible? .

    En C89 (y, por lo tanto, en Microsoft C), no hay ninguna statement sobre lo que sucede si la función main() regresa pero no especifica un valor de retorno; por lo tanto, conduce a un comportamiento indefinido.

    7.22.4.4 La función de exit

    ¶5 Finalmente, el control se devuelve al entorno de host. Si el valor del status es cero o EXIT_SUCCESS , se EXIT_SUCCESS una forma definida por la implementación del estado de finalización exitosa . Si el valor del status es EXIT_FAILURE , se EXIT_FAILURE una forma definida por la implementación de la terminación de estado fallido . De lo contrario, el estado devuelto está definido por la implementación.

    Estándar C ++ – Entorno hospedado

    El estándar C ++ 11 (ISO / IEC 14882: 2011) dice:

    3.6.1 Función principal [basic.start.main]

    ¶1 Un progtwig debe contener una función global llamada main, que es el inicio designado del progtwig. […]

    ¶2 Una implementación no debe predefinir la función principal. Esta función no debe estar sobrecargada. Tendrá un tipo de retorno de tipo int, pero de lo contrario su tipo está definido por la implementación. Todas las implementaciones permitirán ambas de las siguientes definiciones de main:

     int main() { /* ... */ } 

    y

     int main(int argc, char* argv[]) { /* ... */ } 

    En la última forma, argc será el número de argumentos pasados ​​al progtwig desde el entorno en el que se ejecuta el progtwig. Si argc es distinto de cero, estos argumentos se suministrarán en argv[0] través de argv[argc-1] como punteros a los caracteres iniciales de cadenas multibyte terminadas en nulo (NTMBS) (17.5.2.1.4.2) y argv[0] serán el puntero al carácter inicial de un NTMBS que representa el nombre utilizado para invocar el progtwig o "" . El valor de argc debe ser no negativo. El valor de argv[argc] será 0. [Nota: se recomienda añadir cualquier parámetro adicional (opcional) después de argv . -Finalizar nota]

    ¶3 La función main no debe usarse dentro de un progtwig. El enlace (3.5) de main está definido por la implementación. […]

    ¶5 Una instrucción return en main tiene el efecto de dejar la función principal (destruir cualquier objeto con duración de almacenamiento automático) y llamar a std::exit con el valor de retorno como argumento. Si el control llega al final de main sin encontrar una instrucción return, el efecto es el de ejecutar

     return 0; 

    El estándar de C ++ dice explícitamente que “[la función principal] tendrá un tipo de retorno de tipo int , pero de lo contrario su tipo está definido para la implementación”, y requiere las mismas dos firmas que el estándar C para ser admitido como opciones. Entonces, un ‘void main ()’ no está directamente permitido por el estándar de C ++, aunque no hay nada que pueda hacer para detener una implementación no estándar que permita alternativas. Tenga en cuenta que C ++ prohíbe al usuario llamar a main (pero el estándar C no lo hace).

    Hay un párrafo de §18.5 Inicio y terminación en el estándar C ++ 11 que es idéntico al párrafo de §7.22.4.4 La función de exit en el estándar C11 (citado anteriormente), aparte de una nota al pie (que simplemente documenta que EXIT_SUCCESS y EXIT_FAILURE están definidos en ).

    Estándar C – Extensión común

    Clásicamente, los sistemas Unix admiten una tercera variante:

     int main(int argc, char **argv, char **envp) { ... } 

    El tercer argumento es una lista de punteros terminados en nulo para cadenas, cada una de las cuales es una variable de entorno que tiene un nombre, un signo igual y un valor (posiblemente vacío). Si no lo usa, puede acceder al entorno a través del entorno ‘ extern char **environ; ‘. Durante mucho tiempo, no tenía un encabezado que lo declarara, pero el estándar POSIX 2008 ahora requiere que se declare en .

    Esto es reconocido por el estándar C como una extensión común, documentada en el Anexo J:

    J.5.1 Argumentos del entorno

    ¶1 En un entorno alojado, la función principal recibe un tercer argumento, char *envp[] , que apunta a un conjunto de punteros terminados en nulo en char , cada uno de los cuales apunta a una cadena que proporciona información sobre el entorno para esta ejecución del progtwig (5.1.2.2.1).

    Microsoft C

    El comstackdor de Microsoft VS 2010 es interesante. El sitio web dice:

    La syntax de statement para main es

      int main(); 

    u, opcionalmente,

     int main(int argc, char *argv[], char *envp[]); 

    Alternativamente, las funciones main y wmain se pueden declarar como wmain void (sin valor de retorno). Si declara main o wmain como wmain void, no puede devolver un código de salida al proceso principal o al sistema operativo mediante el uso de una statement return. Para devolver un código de salida cuando main o wmain se declara void , debe usar la función de exit .

    No está claro para mí qué sucede (qué código de salida se devuelve al sistema principal o al sistema operativo) cuando un progtwig con void main() sale y el sitio web de MS también permanece en silencio.

    Curiosamente, MS no prescribe la versión de dos argumentos de main() que requieren los estándares C y C ++. Solo prescribe una forma de tres argumentos donde el tercer argumento es char **envp , un puntero a una lista de variables de entorno.

    La página de Microsoft también enumera otras alternativas: wmain() que toma cadenas de caracteres anchas, y algunas más.

    La versión de Microsoft Visual Studio 2005 de esta página no enumera void main() como alternativa. Las versiones de Microsoft Visual Studio 2008 en adelante lo hacen.

    Estándar C – Ambiente independiente

    Como se señaló al principio, los requisitos anteriores se aplican a los entornos alojados. Si está trabajando con un entorno independiente (que es la alternativa a un entorno alojado), entonces el estándar tiene mucho menos que decir. Para un entorno independiente, la función llamada al inicio del progtwig no necesita llamarse main y no hay restricciones en su tipo de devolución. El estándar dice:

    5.1.2 Entornos de ejecución

    Se definen dos entornos de ejecución: independientes y alojados. En ambos casos, el inicio del progtwig se produce cuando el entorno de ejecución llama a una función C designada. Todos los objetos con duración de almacenamiento estática deberán inicializarse (establecerse en sus valores iniciales) antes del inicio del progtwig. La manera y el momento de tal inicialización no están especificados. La terminación del progtwig devuelve el control al entorno de ejecución.

    5.1.2.1 Entorno independiente

    En un entorno independiente (en el que la ejecución del progtwig C puede tener lugar sin ningún beneficio de un sistema operativo), el nombre y el tipo de la función llamada al inicio del progtwig están definidos por la implementación. Cualquier instalación de biblioteca disponible para un progtwig independiente, que no sea el conjunto mínimo requerido por la cláusula 4, está definida por la implementación.

    El efecto de la finalización del progtwig en un entorno independiente está definido por la implementación.

    La referencia cruzada a la cláusula 4 Conformidad se refiere a esto:

    ¶5 Un progtwig estrictamente conforme deberá usar solo aquellas características del idioma y la biblioteca especificadas en esta norma internacional. 3) No producirá salida dependiente de ningún comportamiento no especificado, indefinido o definido por la implementación, y no deberá exceder ningún límite mínimo de implementación.

    ¶6 Las dos formas de implementación conforme están alojadas y son independientes . Una implementación alojada conforme aceptará cualquier progtwig estrictamente conforme. Una implementación independiente conforme aceptará cualquier progtwig estrictamente conforme en el que el uso de las características especificadas en la cláusula de la biblioteca (cláusula 7) se limite al contenido de los encabezados estándar , , , , , , , y . Una implementación conforme puede tener extensiones (incluidas funciones de biblioteca adicionales), siempre que no alteren el comportamiento de ningún progtwig estrictamente conforme. 4)

    ¶7 Un progtwig conforme es aquel que es aceptable para una implementación conforme. 5)

    3) Un progtwig estrictamente conforme puede usar características condicionales (ver 6.10.8.3) siempre que el uso esté protegido por una directiva apropiada de preprocesamiento de inclusión condicional que utilice la macro relacionada. Por ejemplo:

     #ifdef __STDC_IEC_559__ /* FE_UPWARD defined */ /* ... */ fesetround(FE_UPWARD); /* ... */ #endif 

    4) Esto implica que una implementación conforme no reserva identificadores distintos a los explícitamente reservados en esta Norma Internacional.

    5) Los progtwigs estrictamente conformes están destinados a ser totalmente portátiles entre implementaciones conformes. Los progtwigs conformes pueden depender de características no portátiles de una implementación conforme.

    Es notable que el único encabezado requerido de un entorno independiente que realmente define cualquier función es (e incluso esos pueden ser, y a menudo lo son, solo macros).

    Estándar C ++ – Ambiente independiente

    Del mismo modo que el estándar C reconoce tanto el entorno alojado como el independiente, también lo hace el estándar C ++. (Citas de ISO / IEC 14882: 2011).

    1.4 Cumplimiento de la implementación [intro.comliance]

    ¶7 Se definen dos tipos de implementaciones: una implementación alojada y una implementación independiente . Para una implementación alojada, esta Norma Internacional define el conjunto de bibliotecas disponibles. Una implementación independiente es aquella en la que la ejecución puede tener lugar sin el beneficio de un sistema operativo, y tiene un conjunto de bibliotecas definido por la implementación que incluye ciertas bibliotecas de soporte de lenguaje (17.6.1.3).

    ¶8 Una implementación conforme puede tener extensiones (incluidas funciones de biblioteca adicionales), siempre que no alteren el comportamiento de ningún progtwig bien formado. Se requieren implementaciones para diagnosticar progtwigs que usan tales extensiones que están mal formadas de acuerdo con este Estándar Internacional. Sin embargo, una vez hecho esto, pueden comstackr y ejecutar dichos progtwigs.

    ¶9 Cada implementación debe incluir documentación que identifique todas las construcciones condicionalmente admitidas que no admite y define todas las características específicas de la configuración regional. 3

    3) Esta documentación también define el comportamiento definido por la implementación; ver 1.9.

    17.6.1.3 Implementaciones autónomas [cumplimiento]

    Se definen dos tipos de implementaciones: alojado y autónomo (1.4). Para una implementación alojada, esta Norma Internacional describe el conjunto de encabezados disponibles.

    Una implementación independiente tiene un conjunto de encabezados definido por la implementación. Este conjunto debe incluir al menos los encabezados que se muestran en la Tabla 16.

    La versión del encabezado suministrada declarará al menos las funciones abort , atexit , at_quick_exit , exit y quick_exit (18.5). Los otros encabezados enumerados en esta tabla deberán cumplir los mismos requisitos que para una implementación alojada.

    Tabla 16: encabezados C ++ para implementaciones independientes

     Subclause Header(s)  18.2 Types  18.3 Implementation properties    18.4 Integer types  18.5 Start and termination  18.6 Dynamic memory management  18.7 Type identification  18.8 Exception handling  18.9 Initializer lists  18.10 Other runtime support    20.9 Type traits  29 Atomics  

    ¿Qué pasa con el uso de int main() en C?

    El estándar §5.1.2.2.1 del estándar C11 muestra la notación preferida – int main(void) – pero también hay dos ejemplos en el estándar que muestran int main() : §6.5.3.4 ¶8 y §6.7.6.3 ¶20 . Ahora, es importante observar que los ejemplos no son ‘normativos’; ellos son solo ilustrativos. Si hay errores en los ejemplos, no afectan directamente el texto principal del estándar. Dicho esto, son muy indicativos del comportamiento esperado, por lo que si el estándar incluye int main() en un ejemplo, sugiere que int main() no está prohibido, incluso si no es la notación preferida.

    6.5.3.4 Los operadores sizeof y _Alignof

    ¶8 EJEMPLO 3 En este ejemplo, el tamaño de una matriz de longitud variable se calcula y devuelve de una función:

     #include  size_t fsize3(int n) { char b[n+3]; // variable length array return sizeof b; // execution time sizeof } int main() { size_t size; size = fsize3(10); // fsize3 returns 13 return 0; } 

    Creo que main() debería devolver EXIT_SUCCESS o EXIT_FAILURE . Se definen en stdlib.h

    Devuelve 0 en caso de éxito y no cero en error. Este es el estándar utilizado por los scripts de UNIX y DOS para averiguar qué sucedió con su progtwig.

    Tenga en cuenta que los estándares C y C ++ definen dos tipos de implementaciones: independiente y alojada.

    • Entorno alojado C90

      Formularios permitidos 1 :

       int main (void) int main (int argc, char *argv[]) main (void) main (int argc, char *argv[]) /*... etc, similar forms with implicit int */ 

      Comentarios:

      Los dos primeros se declaran explícitamente como los formularios permitidos, los demás se permiten implícitamente porque C90 permitió “int implícito” para el tipo de retorno y los parámetros de la función. No se permite ninguna otra forma.

    • Entorno independiente C90

      Cualquier forma o nombre de main está permitido 2 .

    • Entorno alojado C99

      Formularios permitidos 3 :

       int main (void) int main (int argc, char *argv[]) /* or in some other implementation-defined manner. */ 

      Comentarios:

      C99 eliminó “implicit int” así que main() ya no es válido.

      Se ha introducido una oración extraña y ambigua “o de alguna otra manera definida por la implementación”. Esto puede interpretarse como “los parámetros de int main() pueden variar” o como “main puede tener cualquier forma definida por la implementación”.

      Algunos comstackdores han elegido interpretar el estándar de la última manera. Podría decirse que no se puede afirmar fácilmente que no se están ajustando estrictamente al citar el estándar en sí mismo, ya que es ambiguo.

      Sin embargo, para permitir formas completamente salvajes de main() probablemente (?) No era la intención de esta nueva oración. El razonamiento C99 (no normativo) implica que la oración se refiere a parámetros adicionales a int main 4 .

      Sin embargo, la sección para la terminación del progtwig de entorno alojado continúa argumentando sobre el caso donde main no devuelve int 5 . Aunque esa sección no es normativa sobre cómo se debe declarar main, definitivamente implica que main podría declararse de una manera completamente definida por la implementación incluso en sistemas alojados.

    • Ambiente independiente C99

      Cualquier forma o nombre de main está permitido 6 .

    • Entorno alojado C11

      Formularios permitidos 7 :

       int main (void) int main (int argc, char *argv[]) /* or in some other implementation-defined manner. */ 
    • C11 ambiente independiente

      Cualquier forma o nombre de main está permitido 8 .


    Tenga en cuenta que int main() nunca se incluyó en la lista como un formulario válido para cualquier implementación alojada de C en cualquiera de las versiones anteriores. En C, a diferencia de C ++, () y (void) tienen diferentes significados. El primero es una característica obsoleta que puede eliminarse del idioma. Vea las direcciones futuras del lenguaje C11:

    6.11.6 Declaradores de funciones

    El uso de declaradores de función con paréntesis vacíos (no declaradores de tipo de parámetro de formato prototipo) es una característica obsoleta.


    • C ++ 03 entorno alojado

      Forma permitida 9 :

       int main () int main (int argc, char *argv[]) 

      Comentarios:

      Tenga en cuenta el paréntesis vacío en la primera forma. C ++ y C son diferentes en este caso, porque en C ++ esto significa que la función no toma parámetros. Pero en C significa que puede tomar cualquier parámetro.

    • C ++ 03 entorno independiente

      El nombre de la función llamada al inicio está definido por la implementación. Si se llama main() , debe seguir las formas establecidas 10 :

       // implementation-defined name, or int main () int main (int argc, char *argv[]) 
    • C ++ 11 entorno alojado

      Formularios permitidos 11 :

       int main () int main (int argc, char *argv[]) 

      Comentarios:

      El texto del estándar ha sido cambiado pero tiene el mismo significado.

    • C ++ 11 entorno independiente

      El nombre de la función llamada al inicio está definido por la implementación. Si se llama main() , debe seguir las formas establecidas 12 :

       // implementation-defined name, or int main () int main (int argc, char *argv[]) 

    Referencias

    1. ANSI X3.159-1989 2.1.2.2 Entorno hospedado. “Inicio del progtwig”

      La función llamada al inicio del progtwig se llama main. La implementación no declara ningún prototipo para esta función. Se definirá con un tipo de retorno de int y sin parámetros:

       int main(void) { /* ... */ } 

      o con dos parámetros (a los que se hace referencia aquí como argc y argv, aunque se pueden usar los nombres, ya que son locales para la función en la que se declaran):

       int main(int argc, char *argv[]) { /* ... */ } 
    2. ANSI X3.159-1989 2.1.2.1 Entorno independiente:

      En un entorno independiente (en el que la ejecución del progtwig C puede tener lugar sin ningún beneficio de un sistema operativo), el nombre y el tipo de la función llamada al inicio del progtwig están definidos por la implementación.

    3. ISO 9899: 1999 5.1.2.2 Entorno hospedado -> 5.1.2.2.1 Inicio del progtwig

      La función llamada al inicio del progtwig se llama main. La implementación no declara ningún prototipo para esta función. Se definirá con un tipo de retorno de int y sin parámetros:

       int main(void) { /* ... */ } 

      o con dos parámetros (a los que se hace referencia aquí como argc y argv, aunque se pueden usar los nombres, ya que son locales para la función en la que se declaran):

       int main(int argc, char *argv[]) { /* ... */ } 

      o equivalente; 9) o de alguna otra manera definida por la implementación.

    4. Justificación del estándar internacional – Lenguajes de progtwigción – C, Revisión 5.10. 5.1.2.2 Entorno hospedado -> 5.1.2.2.1 Inicio del progtwig

      El comportamiento de los argumentos a main, y de la interacción de exit, main y atexit (ver §7.20.4.2) ha sido codificado para frenar una variedad no deseada en la representación de cadenas de argv, y en el significado de los valores devueltos por main.

      La especificación de argc y argv como argumentos principales reconoce una extensa práctica previa. argv [argc] debe ser un puntero nulo para proporcionar una verificación redundante para el final de la lista, también sobre la base de la práctica común.

      main es la única función que puede ser declarada portablemente con cero o dos argumentos. (El número de argumentos de otras funciones debe coincidir exactamente entre la invocación y la definición.) Este caso especial simplemente reconoce la práctica generalizada de dejar los argumentos en main cuando el progtwig no accede a las cadenas de argumentos del progtwig. Si bien muchas implementaciones admiten más de dos argumentos para main, dicha práctica no está bendecida ni prohibida por el Estándar; un progtwig que define main con tres argumentos no es estrictamente conforme (ver §J.5.1.).

    5. ISO 9899: 1999 5.1.2.2 Entorno hospedado -> 5.1.2.2.3 Terminación del progtwig

      If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument;11) reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.

    6. ISO 9899:1999 5.1.2.1 Freestanding environment

      In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined.

    7. ISO 9899:2011 5.1.2.2 Hosted environment -> 5.1.2.2.1 Program startup

      This section is identical to the C99 one cited above.

    8. ISO 9899:1999 5.1.2.1 Freestanding environment

      This section is identical to the C99 one cited above.

    9. ISO 14882:2003 3.6.1 Main function

      An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main:

       int main() { /* ... */ } 

      y

       int main(int argc, char* argv[]) { /* ... */ } 
    10. ISO 14882:2003 3.6.1 Main function

      It is implementation-defined whether a program in a freestanding environment is required to define a main function.

    11. ISO 14882:2011 3.6.1 Main function

      An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both

      — a function of () returning int and

      — a function of (int, pointer to pointer to char) returning int

      as the type of main (8.3.5).

    12. ISO 14882:2011 3.6.1 Main function

      This section is identical to the C++03 one cited above.

    Keep in mind that,even though you’re returning an int, some OSes (Windows) truncate the returned value to a single byte (0-255).

    main() in C89 and K&R C unspecified return types default to ‘int`.

     return 1? return 0? 
    1. If you do not write a return statement in int main() , the closing { will return 0 by default.

    2. return 0 or return 1 will be received by the parent process. In a shell it goes into a shell variable, and if you are running your program form a shell and not using that variable then you need not worry about the return value of main() .

    See How can I get what my main function has returned? .

     $ ./a.out $ echo $? 

    This way you can see that it is the variable $? which receives the least significant byte of the return value of main() .

    In Unix and DOS scripting, return 0 on success and non-zero for error are usually returned. This is the standard used by Unix and DOS scripting to find out what happened with your program and controlling the whole flow.

    The return value can be used by the operating system to check how the program was closed.

    Return value 0 usually means OK in most operating systems (the ones I can think of anyway).

    It also can be checked when you call a process yourself, and see if the program exited and finished properly.

    It’s NOT just a programming convention.

    The return value of main() shows how the program exited. If the return value is zero it means that the execution was successful while any non-zero value will represent that something went bad in the execution.

    I was under the impression that standard specifies that main doesn’t need a return value as a successful return was OS based (zero in one could be either a success or a failure in another), therefore the absence of return was a cue for the compiler to insert the successful return itself.

    However I usually return 0.

    Returning 0 should tell the programmer that the program has successfully finished the job.

    What to return depends on what you want to do with the executable. For example if you are using your program with a command line shell, then you need to return 0 for a success and a non zero for failure. Then you would be able to use the program in shells with conditional processing depending on the outcome of your code. Also you can assign any nonzero value as per your interpretation, for example for critical errors different program exit points could terminate a program with different exit values , and which is available to the calling shell which can decide what to do by inspecting the value returned. If the code is not intended for use with shells and the returned value does not bother anybody then it might be omitted. I personally use the signature int main (void) { .. return 0; .. }

    If you really have issues related to efficiency of returning an integer from a process, you should probably avoid to call that process so many times that this return value becomes an issue.

    If you are doing this (call a process so many times), you should find a way to put your logic directly inside the caller, or in a DLL file, without allocate a specific process for each call; the multiple process allocations bring you the relevant efficiency problem in this case.

    In detail, if you only want to know if returning 0 is more or less efficient than returning 1, it could depend from the compiler in some cases, but generically, assuming they are read from the same source (local, field, constant, embedded in the code, function result, etc.) it requires exactly the same number of clock cycles.

    In C++ the main function should be declared as int main() and not void main() as the compiler then throws an error in the case of void main. The main function can take any number of arguments like int main(int k,int l,int arr[]) or int main(void).

     #include  using namespace std; int main(void) { // your code goes here cout< <"a"; return 0; } 

    Salida:

     Success #stdin #stdout 0s 4416KB a 

    Coming to the return part it should return only 0 else the compiler throws an error. for example if you return 1,you will get the desired output but it also throws a runtime error.

    Ejemplo

     #include  using namespace std; int main(int k,float m,char g, int arr[]) { // your code goes here k=0; cout<  

    Salida:

     Runtime error #stdin #stdout 0s 4448KB 0aa 

    Here is a small demonstration of the usage of return codes…

    When using the various tools that the Linux terminal provides one can use the return code for example for error handling after the process has been completed. Imagine that the following text file myfile is present:

    This is some example in order to check how grep works.

    When you execute the grep command a process is created. Once it is through (and didn’t break) it returns some code between 0 and 255. For example:

     $ grep order myfile 

    Si lo haces

     $ echo $? $ 0 

    you will get a 0. Why? Because grep found a match and returned an exit code 0, which is the usual value for exiting with a success. Let’s check it out again but with something that is not inside our text file and thus no match will be found:

     $ grep foo myfile $ echo $? $ 1 

    Since grep failed to match the token “foo” with the content of our file the return code is 1 (this is the usual case when a failure occurs but as stated above you have plenty of values to choose from).

    Now the following bash script (simply type it in a Linux terminal) although very basic should give some idea of error handling:

     $ grep foo myfile $ CHECK=$? $ [ $CHECK -eq 0] && echo 'Match found' $ [ $CHECK -ne 0] && echo 'No match was found' $ No match was found 

    After the second line nothing is printed to the terminal since “foo” made grep return 1 and we check if the return code of grep was equal to 0. The second conditional statement echoes its message in the last line since it is true due to CHECK == 1.

    As you can see if you are calling this and that process it is sometimes essential to see what it has returned (by the return value of main()).

    Omit return 0

    When a C or C++ program reaches the end of main the compiler will automatically generate code to return 0, so there is no need to put return 0; explicitly at the end of main .

    Note: when I make this suggestion, it’s almost invariably followed by one of two kinds of comments: “I didn’t know that.” or “That’s bad advice!” My rationale is that it’s safe and useful to rely on compiler behavior explicitly supported by the standard. For C, since C99; see ISO/IEC 9899:1999 section 5.1.2.2.3:

    […] a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument; reaching the } that terminates the main function returns a value of 0.

    For C++, since the first standard in 1998; see ISO/IEC 14882:1998 section 3.6.1:

    If control reaches the end of main without encountering a return statement, the effect is that of executing return 0;

    All versions of both standards since then (C99 and C++98) have maintained the same idea. We rely on automatically generated member functions in C++, and few people write explicit return; statements at the end of a void function. Reasons against omitting seem to boil down to “it looks weird” . If, like me, you’re curious about the rationale for the change to the C standard read this question . Also note that in the early 1990s this was considered “sloppy practice” because it was undefined behavior (although widely supported) at the time.

    So I advocate omitting it; others disagree (often vehemently!) In any case, if you encounter code that omits it, you’ll know that it’s explicitly supported by the standard and you’ll know what it means.

    What is the correct (most efficient) way to define the main() function in C and C++ — int main() or void main() — and why?

    Those words “(most efficient)” don’t change the question. Unless you’re in a freestanding environment, there is one universally correct way to declare main() , and that’s as returning int.

    What should main() return in C and C++?

    It’s not what should main() return, it’s what does main() return. main() is, of course, a function that someone else calls. You don’t have any control over the code that calls main() . Therefore, you must declare main() with a type-correct signature to match its caller. You simply don’t have any choice in the matter. You don’t have to ask yourself what’s more or less efficient, or what’s better or worse style, or anything like that, because the answer is already perfectly well defined, for you, by the C and C+ standards. Just follow them.

    If int main() then return 1 or return 0?

    0 for success, nonzero for failure. Again, not something you need to (or get to) pick: it’s defined by the interface you’re supposed to be conforming to.

    This basically depends on your execution environment (the OS). C implies that it will be run by a UNIX like OS which expects the program to return a (small? 1 Byte? can’t remember) integer to indicate success / failure.

    You should probably just use int main(int argc, char** argv) .