From 2725555872008523674 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,314ebdf2ff957e27 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-04-28 22:54:55 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: kanze@gabi-soft.de (James Kanze) Newsgroups: comp.std.c++ Subject: Re: Why int main()? Date: Tue, 29 Apr 2003 05:54:53 +0000 (UTC) Organization: http://groups.google.com/ Lines: 96 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <3E9821CE.8AC8B8C6@web.de> <7f2735a5.0304161119.2d516e7d@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1051595693 4815 10.0.0.1 (29 Apr 2003 05:54:53 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 29 Apr 2003 05:54:53 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 19AO4q-0001FW-00 for mail2news@news.news.demon.net; Tue, 29 Apr 2003 05:54:52 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id PAA27180; Tue, 29 Apr 2003 15:54:49 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: 28 Apr 2003 07:42:21 GMT X-Spam-Status: No, hits=-8.4 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Xref: archiver1.google.com comp.std.c++:19044 ron@sensor.com ("Ron Natalie") wrote in message news:... > "James Kanze" wrote in message > news:d6651fb6.0304250502.36818e4d@posting.google.com... > > You mean, dynamically change the return type of a function at > > run-time? We could do that to, I suppose, but I don't think that the > > results should be called C or C++. (Maybe lisp?) > No, I thought you were asking that the programmer be able to define an > arbitrary main return type (at compile time). Not that the programmer could definite it. What could the system possibly do with a MyClass if I decide to return that. The only thing I don't see is why given that we allow the implementation to define additional signatures for main, we insist that these additional, non-standard signatures have the return type int. > > What's bad, then, is the same thing that is bad whenever you use an > > implementation defined extension on a system which doesn't define > > it. How is this any different than using: > Who's talking about implentation defined extension? I thought we were. > I think the thread got lost at some point. My impression as well. > I thought we were talking about required main signatures. Frankly, > there really ought to only be one (int main(int, char**)). The only > reason C90 supported otherwise (and now we're stuck with it), is that > most (UNIX) existing implmenetations just happened to do the right > thing if you under declared the actual number of arguments. Totally agreed. I have no particular problem for allowing the implementation to define additional signatures. I don't see a particular need for it, but again, for historical reasons, we're probably stuck with at least allowing: int main( int, char**, char** ) And if we allow additional, implementation defined signatures, I find really only two defensible positions: - an implementation may add additional arguments after the two in the required signature, or - an implementation can pretty much do whatever it wants. We're somewhere between the two positions; something like: int main( char*, double ) is a legal extension, but void main( int, char** ) isn't. And I'll admit that I find THAT fairly arbitrary. > The more you require gunking up the main's function type, the more you > make it difficult for further implementations who don't use a > subroutine linkage compatible with assumptions made for PDP-11's. > > BTW: do you (or anyone else, for that matter) actually know of a > > machine where misdeclaring an int return type as void will cause > > problems if the function doesn't return. I know that there are > > frequently differences between int and a struct (often, if the > > return type is a struct, the compiler will pass a hidden first > > parameter to the address of memory where it should be returned), but > > I've never actually heard of a machine that didn't return an int in > > a register. > Nope, but do you want to preclude this? You were the one who wanted to > wide the type. Me. I didn't want anything. The only signature I ever use (regardless of what the implementation supports) is "int main( int, char** )". Logically, I would argue that 1) it would perhaps be better if the implementation could define the return type (and the parameter type for exit), and the only guaranteed legal values were EXIT_SUCCESS and EXIT_FAILURE, and 2) IF we allow additional implementation defined signatures (and we do), there is really no reason to restrict the return type of THEM. -- James Kanze GABI Software mailto:kanze@gabi-soft.fr Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16 --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]