Not really. The point is that a program has to return a value
to the operating system somehow when it terminates. And int (or
a subset of int values) seems to be the universal type for this,
although on some systems, a 0 value was used to indicate failure
(whereas under Unix or Windows, 0 indicates success); on such
systems, the runtime will have to map the return values to
something else, since the standard requires return 0 to signify
success.
I don't quite understand your tirade about this: Windows and
Unix are fully identical in this respect.
In C, what often happened was that the program would call exit()
from some deeply nested function, and thus never "return" from
main. In C++, this is frowned upon, since it means that
destructors of the local variables are not called.
And of course, there are programs which never terminate
normally. I've worked on a lot of programs for Unix which are
automatically started in the initialization phase of booting,
and never stop. Arguably, "void main" makes sense for such
programs, but they seem to be more common under Unix than under
Windows.
That is also a very interesting 'exception' for main(). Why
should main() be excluded from normal return checking?
Good question. The standard says that falling off the end of
main() is the equivalent of returning 0, and falling off the end
of any other function is undefined behavior.
Generally speaking, however, it's pretty rare that just
returning zero is appropriate behavior. You normally want to
inform the system whether the program has failed or not, so it
can take appropriate actions.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See
http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
