To proste pytanie, ale wciąż widzę sprzeczne odpowiedzi: czy główna procedura programu C ++ powinna powrócić, 0
czy EXIT_SUCCESS
?
#include <cstdlib>
int main(){return EXIT_SUCCESS;}
lub
int main(){return 0;}
Czy są dokładnie tym samym? Powinien EXIT_SUCCESS
być używany tylko z exit()
?
Pomyślałem, EXIT_SUCCESS
że będzie to lepsza opcja, ponieważ inne oprogramowanie może chcieć uznać zero za awarię, ale słyszałem również, że jeśli wrócisz 0
, kompilator i tak jest w stanie zmienić to na inną wartość.
c++
c
return-value
main
Trevor Hickey
źródło
źródło
0
iEXIT_SUCCESS
obie są interpretowane jako sukces.Odpowiedzi:
EXIT_FAILURE
, albo w instrukcji return w,main
albo jako argument doexit()
, jest jedynym przenośnym sposobem wskazania błędu w programie w języku C lub C ++.exit(1)
może faktycznie sygnalizować pomyślne zakończenie na przykład w VMS.Jeśli zamierzasz używać,
EXIT_FAILURE
gdy program zawiedzie, równie dobrze możesz użyć,EXIT_SUCCESS
gdy się powiedzie, tylko ze względu na symetrię.Z drugiej strony, jeśli program nigdy nie sygnalizuje awarii, możesz użyć opcji
0
lubEXIT_SUCCESS
. Oba są gwarantowane przez standard, aby zasygnalizować pomyślne ukończenie. (Jest prawie niemożliwe, abyEXIT_SUCCESS
mieć wartość inną niż 0, ale jest równa 0 w każdej implementacji, o której słyszałem).Używanie
0
ma niewielką zaletę, której nie potrzebujesz#include <stdlib.h>
w C lub#include <cstdlib>
C ++ (jeśli używaszreturn
instrukcji zamiast wywoływaćexit()
) - ale w przypadku programu o dowolnym znaczącym rozmiarze będziesz dołączać stdlib bezpośrednio lub pośrednio tak czy siak.Jeśli o to chodzi, w C, począwszy od standardu 1999, i we wszystkich wersjach C ++, dotarcie do końca i
main()
tak jest niejawnereturn 0;
, więc może nie być konieczne użycie jednej z nich0
lubEXIT_SUCCESS
jawnie. (Ale przynajmniej w C uważam, że wyraźniejszyreturn 0;
jest lepszy styl).(Ktoś poprosił o OpenVMS. Nie używałem go od dłuższego czasu, ale o ile pamiętam nieparzyste wartości stanu na ogół oznaczają sukces podczas gdy wartości nawet oznaczać awarię. Realizacja C odwzorowuje
0
się1
tak, żereturn 0;
wskazuje na pomyślne zakończenie. Inne wartości są przekazywane niezmienione , więcreturn 1;
również wskazuje pomyślne zakończenie.EXIT_FAILURE
miałby wartość parzystą różną od zera).źródło
0
iEXIT_SUCCESS
nie gwarantujemy, że będą miały tę samą wartość (wspomniałem o tym w mojej odpowiedzi), ale oba oznaczają pomyślne zakończenie.EXIT_SUCCESS
jest stylistycznie lepszy, jeśli również używaszEXIT_FAILURE
, aleexit(0)
jest w porządku.Nie ważne. Obie są takie same.
C ++ Standardowe cytaty:
źródło
EXIT_SUCCESS == 0
. Z drugiej strony nie ma dobrego powodu, aby tak nie było.0 jest z definicji magiczną liczbą. EXIT_SUCCESS jest prawie zawsze równe 0, na szczęście. Dlaczego więc nie wrócić / wyjść z 0?
exit (EXIT_SUCCESS); ma bardzo jasne znaczenie.
wyjście (0); z drugiej strony jest pod pewnymi względami sprzeczny z intuicją. Ktoś, kto nie jest zaznajomiony z zachowaniem powłoki, może założyć, że 0 == false == złe, tak jak każde inne użycie 0 w C. Ale nie - w tym jednym szczególnym przypadku 0 == sukces == dobrze. Dla większości doświadczonych deweloperów nie będzie to problemem. Ale po co potykać się z nowym facetem bez absolutnie żadnego powodu?
tl; dr - jeśli istnieje określona stała dla twojej magicznej liczby, prawie nigdy nie ma powodu, aby nie używać tej stałej w pierwszej kolejności. Jest łatwiejszy do przeszukiwania, często bardziej przejrzysty itp. I nic Cię to nie kosztuje.
źródło
fclose()
,setvbuf()
...), POSIX (listen()
,pthread_create()
,pipe()
, ...) i wiele, wiele innych bibliotek (np OpenGL [glGetError()
], zlib [deflate()
/inflate()
/ ...], SDL [SDL_CreateWindowAndRenderer()
/ ...], a więcej).To niekończąca się historia, która odzwierciedla ograniczenia (mit) „ponad wszystko interoperacyjności i przenośności”.
To, co program powinien zwrócić, aby wskazać „sukces”, powinno być określone przez to, kto otrzymuje wartość (system operacyjny lub proces, który wywołał program), a nie przez specyfikację języka.
Jednak programiści lubią pisać kod w „przenośny sposób” i dlatego wymyślają swój własny model pojęcia „systemu operacyjnego” definiującego wartości symboliczne do zwrócenia.
Teraz, w scenariuszu wiele-do-wielu (gdzie wiele języków służy do pisania programów w wielu systemach) zgodność między konwencją językową określającą „sukces” a konwencją systemu operacyjnego (której nikt nie może przyznać, że jest zawsze taka sama) powinna być obsługiwane przez konkretną implementację biblioteki dla określonej platformy docelowej.
Ale - niestety - te koncepcje nie były tak jasne w czasie wdrażania języka C (głównie do pisania jądra UNIX), a gigagramy książek, w których napisano „powrót 0 oznacza sukces”, ponieważ było to prawdą w systemie operacyjnym w tym razem mając kompilator C.
Od tego czasu nie dokonano żadnej jasnej standaryzacji co do tego, jak należy postępować z taką korespondencją. C i C ++ mają swoją własną definicję „wartości zwracanych”, ale nikt nie przyznaje odpowiedniego tłumaczenia systemu operacyjnego (lub lepiej: żadna dokumentacja kompilatora nie mówi o tym). 0 oznacza sukces, jeśli jest prawdziwe dla UNIX - LINUX i - z niezależnych powodów - także dla Windows, a to obejmuje 90% istniejących "komputerów konsumenckich", które - w większości przypadków - pomijają zwracaną wartość (więc możemy dyskutujemy od dziesięcioleci, ale nikt tego nigdy nie zauważy!)
W tym scenariuszu, przed podjęciem decyzji, zadaj następujące pytania: - Czy jestem zainteresowany przekazaniem dzwoniącemu czegoś na temat mojego obecnego? (Jeśli zawsze zwracam 0 ... nie ma pojęcia o tym wszystkim) - Czy mój rozmówca ma konwencje dotyczące tej komunikacji? (Zauważ, że pojedyncza wartość nie jest konwencją: to nie pozwala na jakąkolwiek reprezentację informacji)
Jeśli obie te odpowiedzi brzmią „nie”, prawdopodobnie dobrym rozwiązaniem jest w ogóle nie pisać głównej instrukcji powrotu. (I pozwól kompilatorowi zdecydować, w odniesieniu do celu pracuje).
Jeśli nie ma żadnej konwencji, 0 = sukces spełnia większość sytuacji (a używanie symboli może być problematyczne, jeśli wprowadzają konwencję).
Jeśli konwencje istnieją, upewnij się, że używasz symbolicznych stałych, które są z nimi spójne (i zapewniaj spójność konwencji, a nie spójność wartości, między platformami).
źródło
Kiedy zaczniesz pisać kod, który może zwrócić niezliczone statusy wyjścia, zaczynasz
#define
je wszystkie. W tym przypadkuEXIT_SUCCESS
ma to sens w kontekście nie bycia „ magiczną liczbą ”. To sprawia, że twój kod jest bardziej czytelny, ponieważ każdy inny kod wyjścia będzieEXIT_SOMETHING
. Jeśli po prostu napiszesz program, który zwróci po zakończeniu,return 0
jest prawidłowy i prawdopodobnie nawet bardziej przejrzysty, ponieważ sugeruje brak wyrafinowanej struktury kodu powrotu.źródło
To, co zwracasz z programu, to tylko konwencja.
Nie, nie przychodzą mi do głowy żadne okoliczności, w których „EXIT_SUCCESS” nie byłoby „0”.
Osobiście poleciłbym „0”.
MOIM ZDANIEM...
źródło
0
jest fałszywe, a wiele funkcji powraca0
po niepowodzeniu / nic nie robiąc.Jeśli użyjesz EXIT_SUCCESS, Twój kod będzie bardziej przenośny.
http://www.dreamincode.net/forums/topic/57495-return-0-vs-return-exit-success/
źródło
EXIT_SUCCESS
oba oznaczają pomyślne zakończenie.Niektóre kompilatory mogą powodować z tym problemy - na kompilatorze Mac C ++ EXIT_SUCCESS działało dobrze, ale na kompatybilnym z Linux C ++ musiałem dodać cstdlib, aby wiedzieć, co to jest EXIT_SUCCESS. Poza tym są jednym i tym samym.
źródło
EXIT_SUCCESS
działał bez uwzględnienia jednego<stdlib.h>
lub<cstdlib>
drugiego, musiał go zdefiniować inny nagłówek, bezpośrednio lub pośrednio. W C ++ jest to typowe dla standardowych nagłówków do#include
innych standardowych nagłówków. Jeśli to kompiluje się bez błędów: oznaczaint main() { return EXIT_SUCCESS; }
to, że Twój kompilator prawdopodobnie zawiera błędy.