From -2307557693639174601 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,314ebdf2ff957e27 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-04-15 17:01:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: allan_w@my-dejanews.com (Allan W) Newsgroups: comp.std.c++ Subject: Re: Why int main()? Date: Wed, 16 Apr 2003 00:01:10 +0000 (UTC) Organization: http://groups.google.com/ Lines: 40 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <7f2735a5.0304141217.59268028@posting.google.com> References: <3E9821CE.8AC8B8C6@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1050451270 23580 10.0.0.1 (16 Apr 2003 00:01:10 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 16 Apr 2003 00:01:10 +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 195aMO-00068A-00 for mail2news@news.news.demon.net; Wed, 16 Apr 2003 00:01:09 +0000 X-Received: by mulga.cs.mu.OZ.AU id KAA10928; Wed, 16 Apr 2003 10:01:05 +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: 14 Apr 2003 20:17:51 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++:18759 terekhov@web.de (Alexander Terekhov) wrote > In the next round, I'd probably try to make {thread::}main's return > type "application-chosen" -- other thread(s) (if any) could then join > and obtain whatever-return-value (if it's not void)... and adopt a > rather simple POSIX behavior of "passive exit" on last thread > termination. Oder? ;-) That's assuming a lot. Let's assume that every conforming C++ compiler will have to support threads (a huge assumption!). Let's further assume that when one thread terminates, some other thread (at least the one that spawned it in the first place) is able to get the "return value," no matter how large that might be. You're still making two even bigger assumptions. 1) The process will live as long as *ANY* thread does. As opposed to, "the process will live as long as the FIRST thread does." Seems to me that some OS's won't support this directly; instead, the runtime system will keep control of what the OS calls the main thread, and it can spawn a thread to run a main program. The trouble with this approach is that ALL programs are now multi-threaded. 2) Returning class data from the MAIN thread makes sense. But what happens if the program has only one thread, and it returns data of type customer? What will the OS do with a customer? The OS needs to know if the program ran successfully or not; if not, it might need some indication of generally what went wrong. This sounds a lot like the integer scheme currently in use on all Unix systems, and carefully cloned on almost all other systems (including the MSDOS-subsystem of all Microsoft Windows platforms). --- [ 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 ]