instruction return vs exit () dans main ()

Dois-je utiliser exit()ou simplement des returndéclarations main()? Personnellement, je préfère les returndéclarations car je pense que c'est comme lire n'importe quelle autre fonction et le contrôle de flux lorsque je lis le code est fluide (à mon avis). Et même si je veux refactoriser la main()fonction, avoir returnsemble être un meilleur choix que exit().

Fait exit()quelque chose de spécial qui returnne le fait pas?

En fait, il y a une différence, mais c'est subtil. Il a plus d'implications pour C ++, mais les différences sont importantes.

Quand j'appelle returnà main(), Destructeurs seront appelés à mes objets scope localement. Si j'appelle exit(), aucun destructeur ne sera appelé pour mes objets de portée locale! Relisez ça. exit() ne revient pas . Cela signifie qu'une fois que je l'appelle, il n'y a «aucun backsies». Les objets que vous avez créés dans cette fonction ne seront pas détruits. Souvent, cela n'a aucune implication, mais parfois, comme la fermeture de fichiers (vous voulez sûrement que toutes vos données soient vidées sur le disque?).

Notez que les staticobjets seront nettoyés même si vous appelez exit(). Notez enfin que si vous utilisez abort(), aucun objet ne sera détruit. C'est-à-dire qu'aucun objet global, aucun objet statique et aucun objet local n'auront leurs destructeurs appelés.

Procédez avec prudence lorsque vous privilégiez la sortie au retour.

http://groups.google.com/group/gnu.gcc.help/msg/8348c50030cfd15a

Une autre différence: exitc'est une fonction de bibliothèque standard, vous devez donc inclure des en-têtes et un lien avec la bibliothèque standard. Pour illustrer (en C ++), ceci est un programme valide:

int main() { return 0; }

mais pour l'utiliser, exitvous aurez besoin d'un include:

#include <stdlib.h>
int main() { exit(EXIT_SUCCESS); }

De plus, cela ajoute une hypothèse supplémentaire: que l'appel exitde maina les mêmes effets secondaires que le retour à zéro. Comme d'autres l'ont souligné, cela dépend du type d'exécutable que vous créez (c'est-à-dire qui appelle main). Codez-vous une application qui utilise le C-runtime? Un plugin Maya? Un service Windows? Un chauffeur? Chaque cas nécessitera des recherches pour voir si exitest équivalent à return. À exitmon humble avis, utiliser quand vous voulez vraiment dire return rend le code plus confus. OTOH, si vous voulez vraiment dire exit , alors utilisez-le par tous les moyens.

Il y a au moins une raison de préférer exit: si l'un de vos atexitgestionnaires fait référence à des données de durée de stockage automatique dans main, ou si vous avez utilisé setvbufou setbufpour affecter à l'un des flux standard un tampon de durée de stockage automatique dans main, puis le retour de mainproduit comportement indéfini, mais l'appel exitest valide.

Une autre utilisation potentielle (généralement réservée aux programmes de jouets, cependant) est de quitter un programme avec des invocations récursives de main.

J'utilise toujours returnparce que le prototype standard pour main()dit qu'il retourne un int.

Cela dit, certaines versions des normes accordent mainun traitement spécial et supposent qu'elle renvoie 0 s'il n'y a pas de returndéclaration explicite . Étant donné le code suivant:

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

G ++ génère uniquement un avertissement pour foo()et ignore le retour manquant de main:

% g++ -Wall -c foo.cc
foo.cc: In function ‘int foo()’:
foo.cc:1: warning: control reaches end of non-void function

Je FORTEMENT deuxième le commentaire par R. sur l' utilisation de la sortie () afin d'éviter le stockage automatique main()remis en état avant le programme en fait se termine. Une return X;instruction in main()n'est pas exactement équivalente à un appel à exit(X);, car le stockage dynamique de main()disparaît lors du main()retour, mais il ne disparaît pas si un appel à exit()est effectué à la place.

De plus, en C ou tout autre langage de type C, une returninstruction indique fortement au lecteur que l'exécution se poursuivra dans la fonction appelante, et bien que cette poursuite de l'exécution soit généralement techniquement vraie si vous comptez la routine de démarrage C qui a appelé votre main()fonction, ce n'est pas exactement ce que vous voulez dire lorsque vous voulez mettre fin au processus.

Après tout, si vous souhaitez terminer votre programme à partir de toute autre fonction, sauf que main()vous devez appeler exit(). Le faire de manière cohérente main()rend également votre code beaucoup plus lisible, et il est également beaucoup plus facile pour quiconque de re-factoriser votre code; c'est-à-dire que le code copié depuis main()une autre fonction ne se comportera pas mal en raison de returndéclarations accidentelles qui auraient dû être des exit()appels.

Donc, en combinant tous ces points ensemble, la conclusion est que c'est une mauvaise habitude , au moins pour C, d'utiliser une returndéclaration pour terminer le programme main().

Exit () fait-il quelque chose de spécial que «return» ne fait pas?

Avec certains compilateurs pour les plates-formes inhabituelles, exit()pourrait traduire son argument en valeur de sortie de votre programme tandis qu'un retour de main()pourrait simplement passer la valeur directement à l'environnement hôte sans aucune traduction.

La norme requiert un comportement identique dans ces cas (en particulier, elle indique que renvoyer quelque chose qui est intcompatible à partir de main()devrait être équivalent à appeler exit()avec cette valeur). Le problème est que différents systèmes d'exploitation ont des conventions différentes pour interpréter les valeurs de sortie. Sur de nombreux systèmes (BEAUCOUP!), 0 signifie succès et tout le reste est un échec. Mais sur, par exemple, VMS, les valeurs impaires signifient le succès et même les valeurs signifient l'échec. Si vous renvoyiez 0 de main(), un utilisateur VMS verrait un méchant message concernant une violation d'accès. Il n'y avait pas réellement de violation d'accès - c'était simplement le message standard associé au code d'échec 0.

Puis l'ANSI est venu et a béni EXIT_SUCCESSet EXIT_FAILUREcomme arguments vous pourriez passer exit(). La norme indique également que exit(0)devrait comporter de manière identique à exit(EXIT_SUCCESS), de sorte que la plupart des implémentations définissent EXIT_SUCCESSà 0.

La norme, par conséquent, vous met dans une liaison sur VMS, car elle ne laisse aucun moyen standard de renvoyer un code d' échec qui se trouve avoir la valeur 0.

Le compilateur VAX / VMS C de l'ère du début des années 1990 n'a donc pas interprété la valeur de retour main(), il a simplement renvoyé toute valeur à l'environnement hôte. Mais si vous avez utiliséexit() il ferait ce que la norme exigeait: traduire EXIT_SUCCESS(ou 0) en un code de réussite et EXIT_FAILUREen un code d'échec générique. Pour utiliser EXIT_SUCCESS, vous deviez passer à exit(), on ne pouvait pas retourner à partir main(). Je ne sais pas si des versions plus modernes de ce compilateur ont préservé ce comportement.

Un programme C portable ressemblait à ceci:

#include <stdio.h>
#include <stdlib.h>

int main() {
  printf("Hello, World!\n");
  exit(EXIT_SUCCESS);  /* to get good return value to OS */
  /*NOTREACHED*/ /* to silence lint warning */
  return 0;  /* to silence compiler warning */
}

En plus: Si je me souviens bien, la convention VMS pour les valeurs de sortie est plus nuancée qu'impaire / paire. Il utilise en fait quelque chose comme les trois bits bas pour coder un niveau de gravité. D'une manière générale, cependant, les niveaux de gravité impairs indiquaient le succès ou des informations diverses et les pairs même indiquaient des erreurs.

En C, le retour mainest exactement le même que l'appel exitavec la même valeur.

La section 5.1.2.2.3 de la norme C stipule:

Si le type de retour de la fonction principale est un type compatible avec int, un retour de l'appel initial à la fonction principale équivaut à appeler la fonction exit avec la valeur renvoyée par la fonction principale comme argument ; 11) atteindre le} qui termine la fonction principale renvoie une valeur de 0. Si le type de retour n'est pas compatible avec int, l'état de terminaison renvoyé à l'environnement hôte n'est pas spécifié.

Les règles pour C ++ sont un peu différentes comme mentionné dans d'autres réponses.

Il y a en fait une différence entre exit(0)et return(0)in main- lorsque votre mainfonction est appelée plusieurs fois.

Le programme suivant

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv) {
  if (argc == 0)
    return(0);
  printf("%d", main(argc - 1, argv));
}

Courir comme

./program 0 0 0 0

Se traduira par la sortie suivante:

00000

Cependant celui-ci:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv) {
  if (argc == 0)
    exit(0);
  printf("%d", main(argc - 1, argv));
}

N'imprime rien, quels que soient les arguments.

Si vous êtes sûr que personne n'appellera jamais votre mainexplicitement, ce n'est pas techniquement une grande différence en général, mais conserver un code plus clair exitserait beaucoup mieux. Si, pour une raison quelconque, vous souhaitez appeler main, vous devez l'adapter à vos besoins.

En parlant de C.