From -2275205363728519634
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: f78e5,314ebdf2ff957e27
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 2003-04-23 09:38:00 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!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: Wed, 23 Apr 2003 16:37:59 +0000 (UTC)
Organization: http://groups.google.com/
Lines: 56
Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++)
Message-ID: <d6651fb6.0304230818.25c4cc21@posting.google.com>
References: <Qbvla.955$5Z2.28625@newsfep1-win.server.ntli.net> <RkkxdPDmqwl+Ewp6@robinton.demon.co.uk> <DaGla.19630$ey1.1684332@newsread1.prod.itd.earthlink.net> <9k6f9vkh1959gdaln74lutrdbv9kr9rq0c@4ax.com> <G1Vma.8270$88.2789@fe07.atl2.webusenet.com> <3e9dc9fd$0$4860$ed9e5944@reading.news.pipex.net> <5765b025.0304162335.536cf0ec@posting.google.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: mail2news.demon.co.uk 1051115879 3194 10.0.0.1 (23 Apr 2003 16:37:59 GMT)
X-Complaints-To: abuse@demon.net
NNTP-Posting-Date: Wed, 23 Apr 2003 16:37:59 +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 198NFt-0000pN-00
	for mail2news@news.news.demon.net; Wed, 23 Apr 2003 16:37:58 +0000
X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU
	id CAA03519; Thu, 24 Apr 2003 02:37:55 +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: 23 Apr 2003 16:18:22 GMT
X-Spam-Status: No, hits=-9.1 required=5.0
	tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02
	version=2.41
Xref: archiver1.google.com comp.std.c++:18909

algrant@myrealbox.com (Al Grant) wrote in message
news:<5765b025.0304162335.536cf0ec@posting.google.com>...
> SPAMstephen.howeGUARD@tnsofres.com ("Stephen Howe") wrote in message
> news:<3e9dc9fd$0$4860$ed9e5944@reading.news.pipex.net>...
> > I for one would sanction that main has to have a return statement in
> > the next standard. There is absolutely _NO_ good reason why main
> > cannot behave just like other functions if at all possible (I know
> > it is special).  Dropping "off the bottom" of main is appalling and
> > I am amazed that was retained in the standard when implicit int was
> > removed.

> Right, there is no good reason why main cannot behave just like other
> functions.  But it is other functions that need fixing.  E.g. consider

>    void g(void);
>    int f(bool b) { if (b) return 1; g(); }

> Should this be legal?

It is legal, so the question should be: do we want to make it illegal.

> Sure, if g() calls exit(), or longjmp(), or throws an exception, or
> goes into an infinite loop.

For a more telling example, you should use a return which isn't int.
It's trivial to insert a return 0.  But what do you do if the return
value is a user type which has no trivial constructors, and you have
nothing with which to call the constructors?

> The committee seem to have tentatively grasped the concept of "non
> standard returns" in the context of main without accepting its utility
> in general.

I'm not sure what the committee had in mind when they made the special
rules for int, but 1) the rules can't easily be extended to functions
returning user defined types, and 2) they don't change anything in the
case of functions where you don't fall off the end.  I don't see any
need for the exception.

> Some compilers already provide a "no return" annotation - evidently
> useful for the real world, so why not add it to the language?

To solve what problem?

--
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                       ]



