Greg Comeau wrote:
>
> In article <1f2pqr6.1mhz3ehk2hs8wN%dwalker07@snet.net.invalid>,
> Daryle Walker <dwalker07@snet.net.invalid> wrote:
...
> >AFAIK, the C++ runtime
> >code that happens before and after "main" can be any code, as long as it
> >does program setup/breakdown correctly.  It doesn't have to involve
> >"exit" at all, or only as a part.
>
> It must usually involve exit().  I don't recall that abort() has to
> call exit() though, so that may or may not have to be another issue
> to deal with.

3.6.3p4:
"Calling the function

 void abort()

declared in <cstdlib> terminates the program without executing
destructors for objects of automatic or static duration and without
calling the functions passed to atexit()."

Given that description, I'd say that abort() is prohibited from calling
exit(), otherwise thing that are not supposed to happen will happen.

> >I thought "exit" would only handle
> >the C-specific stuff.  For an environment that doesn't use program
> >return values, the return value of "exit" is superflous.

Incorrect: section 18.3 defines additional things that exit() must do in
a C++ environment. Most notably, it must execute the destructors of all
objects of static duration.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hi,
comeau@panix.com (Greg Comeau) wrote:
> main has other problems besides this, so perhaps it will get
> revisited in C++0x.

Of course, 'main()' should take a proper C++ sequence as argument. Since
the type of the sequence should be left to the implementation and to
avoid dependency to some sequence type, the obvious definition of 'main()'
shall be

  template <typname InIt>
  export void main(InIt begin, InIt end)
  {
    // ...
  }

which returns 'EXIT_SUCCESS' to the calling environment (if this environment
needs a return code from the program) or, to explicitly return a value

  template <typename InIt>
  export int main(InIt begin, InIt end)
  {
    // ...
    return something;
  }

Of course, there shall be no special case for omitting a return statement,
ie. just letting execusion flowing off the end of 'int main()'. The value
type of the iterator is, of course, 'std::string'. For backward compatibility
two 'main()' functions are put into the library which just do the right thing:

  template <typename InIt>
  int main(InIt begin, InIt end)
  {
    std::vector<char const*> args;
    std::transform(begin, end, std::back_inserter(args),
                   std::mem_fun(&std::string::c_str));
    args.push_back(0);
    return main(args.size() - 1, const_cast<char*[]>(&args[0]));
  }

  int main(int ac, char* av[])
  {
    return main();
  }

(I guess all of these code examples are riddled with typos and minor misuses
but the intent should still be transparent...).

Of course, now lots of people will jump on me because we all "know" that the
function 'main()' is a rather special function which is called by the
operating system and it thus cannot possibly be a template function. Well,
face it: The entry point to a C++ program is not all the funciton 'main()'
which is written in C++ code! The entry point to a C++ program is the
function which copes with global object life time, handling of uncaught
exceptions, calling of functions registered with 'atexit()', and a few
other things like calling a user defined function which the user has named
'main()'. Thus, 'main()' can be basically just a normal function which is not
really handled specially: It's address can be taken, it can be instantiated
with additional template arguments (although maybe not explicitly), it can be
called recursively, etc.

BTW, the capability to replace specific function by user defined versions if
these are present is also already supported by all conforming C++
implementations: This is how '::operator new(std::size_t)' and family is
handled...
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote:

> In article <1f27z3z.1603cnt1s8z81mN%darylew@mac.com>, Daryle Walker
> <darylew@mac.com> writes
> >I think this "solution" was a silly (IMHO) way to go.  The int-only guys
> >desired the int-only rule so much that they agreed to bend the grammar
> >to give the void-likers a back door?  I think the int-only guys should
> >have conceded that not all environments demand a return value.  If we
> >could allow "main" not to require "argc" and "argv," we can give up on
> >the int-only return feature too.
>
> That may be, but all programs can be used in contexts where a return
> value IS required unless they are being executed in a free standing
> environment. Personally I would have preferred that main had not been
> special cased to allow omitting the return statement.

In what context is a return value required?  Note that my new rules say
that a return-less "main" in a return-needing environment get an
implicit "return 0" added by the C++ runtime (which calls "main"), so
the language-agsnostic environment never knows the difference.

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Ron Natalie <ron@sensor.com> wrote:

> Daryle Walker wrote:
> >
> > I read a lot of corrections in the various C++ newsgroups that suggest
> > changing "void main()" declarations to "int main()".  This is because
> > standard C++ only allows an "int" return.  This probably came from
> > Unix-based C and C++, which passed the return value of "main" to the
> > environment.  However, other enviroments (Mac, maybe Windows) have no
> > use for a return value.  This leads to C++ writers of those environments
> > to use "void main()", which leads to the compilants I initially
> > mentioned.

> It's bad enough that main is inversely overloaded (it's the only function
> where you provide one definition that and the caller has to resolve which
> of the legal variants of the function the user actually provided).
> Further kludging it up seems pointless.

AFAIK, the only caller of "main" is the C++ runtime.  Unlike C, the
environment can't call "main" directly from the outside, and there can
be no other callers of "main" on the inside, not even itself.  (I think
old versions of C allowed other functions to call "main," even itself
recursively.)  A good C++ compiler environment could recognize which
version of "main" is being used and add the proper recognition to the
C++ runtime code.

> You are right, the allowance of omitting the return value in main is
> inane. It actually has nothing to do with the MAC, the reason is hilarious
> (compatibility with a long ago written snippet of C code which doesn't
> compile anymore in the current standard versions of either C or C++).

Specifics, please?

> I don't see how furhter kluding of main helps anything.

If we take that kind of attitude, why bother to try improving C++ (or
anything else) at all?

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Greg Comeau <comeau@panix.com> wrote:

> In article <1f27z3z.1603cnt1s8z81mN%darylew@mac.com>,
> Daryle Walker <darylew@mac.com> wrote:
[SNIP]
> >However, other enviroments (Mac, maybe Windows) have no
> >use for a return value.  This leads to C++ writers of those environments
> >to use "void main()", which leads to the compilants I initially
> >mentioned.
>
> Well, they could still use int main(), even if the int didn't go
> anywhere (I'm not arguing either way, just pointing out that
> void main doesn't have to be a requirement for such an environment,
> despite it being odd that there is no where to pass the int).

A point I'm trying to make is if we can allow int-ed mains to exist in
environments without returns, why can't be allow the reverse rule to
have void-ed mains in environments with returns?

> >This has resulted in a wierd compromise in the C++ standard: "main"
> >still has to return "int," but a return declaration can be ommitted,
> >like in void-returning functions (and if the return is omitted the
> >function acts like a "return 0" is at its end).
>
> If you mean the above has led to this, then no, I disagree.
> But of course, that doesn't make the situation any less weird.

Then what did lead to this situation?

> >This lets a
> >void-main-user transition to the standard way by just changing the
> >return type of "main."  Unfortunately, it makes C++ grammar irregular
> >(since all function definitions must have a return policy that conforms
> >to the return type, except "main").
>
> Well, some argue it should conforms too.
>
> >I think this "solution" was a silly (IMHO) way to go.  The int-only guys
> >desired the int-only rule so much that they agreed to bend the grammar
> >to give the void-likers a back door?  I think the int-only guys should
> >have conceded that not all environments demand a return value.  If we
> >could allow "main" not to require "argc" and "argv," we can give up on
> >the int-only return feature too.
>
> main has other problems besides this, so perhaps it will get
> revisited in C++0x.

What are the other problems?

> >Maybe it can be like:
> >
> >//=====================================================================
> >On hosted implementations, the main function has one of these
> >signatures:
> >
> >    XX main( );
> >    XX main( int argc, char *argv[] );
> >
> >(where "XX" is explained later).  It can also have signatures that match
> >the second, but with implementation-specified arguments after the two
> >arguments given here.  The return type "XX" can be:
> >
> >    int
> >    void
> >    std::main_t  (defined in <cstddef>)
>
> Don't forget std::string's and stuff like that then.

The standard only allows "int," my idea only allows "int," "void," and
maybe a third type.  We could take your extension and allow arbitrary
types, but:

1.  The types have to be POD, since the development system reduces the
C++ (or any other language) program to language-agnostic assembly code.
This means that smart objects can't be returned, just data.

2.  Arbitrary types could cause an combinatorical explosion on how the
C++ runtime is supposed to convert a return type to what the environment
expects (unless the environment accepts "void," of course).

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <1f2j7wo.1a9bszdw584xmN%dwalker07@snet.net.invalid>, Daryle
Walker <dwalker07@snet.net.invalid> writes
>The standard only allows "int," my idea only allows "int," "void," and
>maybe a third type.  We could take your extension and allow arbitrary
>types, but:

The problem, as I see it, is that main does NOT return directly to the
environment but through another function called exit. I suppose we could
overload exit():

int exit();
int exit(int);

Or even make the declaration of exit:

int exit(int=1);

Perhaps the latter is the right way to go in the process of evolving C++
to be more intuitive.


Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Fri,  9 Nov 2001 10:16:24 CST, Francis Glassborow <francis.glassborow@ntlworld.com> wrote:
>  In article <1f2j7wo.1a9bszdw584xmN%dwalker07@snet.net.invalid>, Daryle
>  Walker <dwalker07@snet.net.invalid> writes
> >The standard only allows "int," my idea only allows "int," "void," and
> >maybe a third type.  We could take your extension and allow arbitrary
> >types, but:
>
>  The problem, as I see it, is that main does NOT return directly to the
>  environment but through another function called exit. I suppose we could
>  overload exit():
>
>  int exit();
>  int exit(int);
>
>  Or even make the declaration of exit:
>
>  int exit(int=1);

   int exit(int = EXIT_SUCCESS);

to be portable.

-- Niklas Matthies
--
The future ain't what it used to be...

---
[ 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.research.att.com/~austern/csc/faq.html                ]

> > You are right, the allowance of omitting the return value in main is
> > inane. It actually has nothing to do with the MAC, the reason is hilarious
> > (compatibility with a long ago written snippet of C code which doesn't
> > compile anymore in the current standard versions of either C or C++).
>
> Specifics, please?
>
The answer I get from those on the standards committee was they wanted
to preserve the K&R "Hello World" program's ability to be compiled in
C++.  It lacks an explicit return from main.  It however, still doesn't
compile as it lacks a explicit declaration of main's return type and
neither C or C++ permits the implicit int anymore.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Daryle Walker wrote:
...
> AFAIK, the only caller of "main" is the C++ runtime.  Unlike C, the
> environment can't call "main" directly from the outside, and there can

I'm not sure what you mean by that. Could you give an example of "the
environment" calling '"main" directly from the outside'? The only thing
I can think of that would qualify is some kind of debugger, but in that
it's no different from C++.

> be no other callers of "main" on the inside, not even itself.  (I think
> old versions of C allowed other functions to call "main," even itself
> recursively.) ...

Current versions, too.

...
> > I don't see how furhter kluding of main helps anything.
>
> If we take that kind of attitude, why bother to try improving C++ (or
> anything else) at all?

He wording strongly implies that he's not talking about something that
he considers an improvement of C++.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Ron Natalie wrote:
> > > You are right, the allowance of omitting the return value in main
> > > is inane. It actually has nothing to do with the MAC, the reason is
> > > hilarious (compatibility with a long ago written snippet of C code
> > > which doesn't compile anymore in the current standard versions of
> > > either C or C++).
> >
> > Specifics, please?
> >
> The answer I get from those on the standards committee was they wanted
> to preserve the K&R "Hello World" program's ability to be compiled in
> C++.  It lacks an explicit return from main.  It however, still doesn't
> compile as it lacks a explicit declaration of main's return type and
> neither C or C++ permits the implicit int anymore.

Interesting.  Actually, I have often wondered why -- given that main()
is exempted from the requirement to have a return statement --  it wasn't
also exempted from the rule disallowing implicit int.  Certainly that
would cause no harm here -- after all, the return type is fixed, and
we have (from ARM C++ compilers) an existence proof that it's not too
difficult for a compiler to implement.  To me, it would make a lot
more sense to allow the int return type for main to be implicit (as
was done for previous versions of C and C++) that to allow void as a
return type, which as far as I know has never been legal.  It also
seems to me that allowing implicit int for main() should be a
satisfactory compromise for those who do not wish to explicitly declare
an int return type because they do not intend to use the returned value.

Incidentally, there is one situation in which I have found it benefecial
that a return statement is optional:  when I have a stand-alone control
program that never terminated.  In that case main() will look something
like this:

int
main () {
    // optional initialization stuff goes here
    for (;;) {
        // code for, e.g., a job dispatcher goes here
    }
}

On some compilers putting a "return 0" statement after the endless loop
draws an "unreachable statement" warning.  Being able to omit the
return statement out avoids that :)

heard

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote:

> In article <1f2j7wo.1a9bszdw584xmN%dwalker07@snet.net.invalid>, Daryle
> Walker <dwalker07@snet.net.invalid> writes
> >The standard only allows "int," my idea only allows "int," "void," and
> >maybe a third type.  We could take your extension and allow arbitrary
> >types, but:
>
> The problem, as I see it, is that main does NOT return directly to the
> environment but through another function called exit. I suppose we could
> overload exit():
>
> int exit();
> int exit(int);
>
> Or even make the declaration of exit:
>
> int exit(int=1);
>
> Perhaps the latter is the right way to go in the process of evolving C++
> to be more intuitive.

Are you sure that you are not thinking about C?  AFAIK, the C++ runtime
code that happens before and after "main" can be any code, as long as it
does program setup/breakdown correctly.  It doesn't have to involve
"exit" at all, or only as a part.  I thought "exit" would only handle
the C-specific stuff.  For an environment that doesn't use program
return values, the return value of "exit" is superflous.

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <1f2pqr6.1mhz3ehk2hs8wN%dwalker07@snet.net.invalid>, Daryle
Walker <dwalker07@snet.net.invalid> writes
>Are you sure that you are not thinking about C?  AFAIK, the C++ runtime
>code that happens before and after "main" can be any code, as long as it
>does program setup/breakdown correctly.  It doesn't have to involve
>"exit" at all, or only as a part.  I thought "exit" would only handle
>the C-specific stuff.  For an environment that doesn't use program
>return values, the return value of "exit" is superflous.
 See 3.6.1 para 5.

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

James Kuyper Jr. <kuyper@wizard.net> wrote:

> Daryle Walker wrote:
> ...
> > AFAIK, the only caller of "main" is the C++ runtime.  Unlike C, the
> > environment can't call "main" directly from the outside, and there can
>
> I'm not sure what you mean by that. Could you give an example of "the
> environment" calling '"main" directly from the outside'? The only thing
> I can think of that would qualify is some kind of debugger, but in that
> it's no different from C++.

In C, there is no behind-the-scences set-up to be done, so the linker
can arrange the executable so the environment calls the program by
calling main directly.  In C++, there has to be background set-up to
handle global constructors, exception handling, etc.; I call this the
C++ runtime code.  The linker arranges the environment to call the
runtime intialization function first instead.  The "main" function gets
called by the runtime code, and not by the environment directly.

> > be no other callers of "main" on the inside, not even itself.  (I think
> > old versions of C allowed other functions to call "main," even itself
> > recursively.) ...
>
> Current versions, too.
[TRUNCATE]

OK.  I guess C still doesn't have any behind-the-scences set-up, so
"main" can be treated like an ordinary function.

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Daryle Walker wrote:
>
> James Kuyper Jr. <kuyper@wizard.net> wrote:
>
> > Daryle Walker wrote:
> > ...
> > > AFAIK, the only caller of "main" is the C++ runtime.  Unlike C, the
> > > environment can't call "main" directly from the outside, and there can
> >
> > I'm not sure what you mean by that. Could you give an example of "the
> > environment" calling '"main" directly from the outside'? The only thing
> > I can think of that would qualify is some kind of debugger, but in that
> > it's no different from C++.
>
> In C, there is no behind-the-scences set-up to be done, so the linker
> can arrange the executable so the environment calls the program by
> calling main directly.
_
Not quite. In the environments where I've used C, the runtime code has
to allocate the stack and the heap, initialize statics, parse the
command line, and set-up argv[] before calling main().

> ... In C++, there has to be background set-up to
> handle global constructors, exception handling, etc.; I call this the
> C++ runtime code.  The linker arranges the environment to call the
> runtime intialization function first instead.  The "main" function gets
> called by the runtime code, and not by the environment directly.

There's certainly more that might need to be done in C++ than in C, but
in neither case is the call direct.

> > > be no other callers of "main" on the inside, not even itself.  (I think
> > > old versions of C allowed other functions to call "main," even itself
> > > recursively.) ...
> >
> > Current versions, too.
> [TRUNCATE]
>
> OK.  I guess C still doesn't have any behind-the-scences set-up, so
> "main" can be treated like an ordinary function.

C does have some behind-the-scenes set-up. Depending upon what main()
does with argv[], it may be necessary for a caller of main() to emulate
that setup.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <1f2pqr6.1mhz3ehk2hs8wN%dwalker07@snet.net.invalid>,
Daryle Walker <dwalker07@snet.net.invalid> wrote:
>Francis Glassborow <francis.glassborow@ntlworld.com> wrote:
>> In article <1f2j7wo.1a9bszdw584xmN%dwalker07@snet.net.invalid>, Daryle
>> Walker <dwalker07@snet.net.invalid> writes
>> >The standard only allows "int," my idea only allows "int," "void," and
>> >maybe a third type.  We could take your extension and allow arbitrary
>> >types, but:

Actually, I wasn't advocating competely arbitary types,
just perhaps some addition ones that should be looked into,
in particular std::string ones.

>> The problem, as I see it, is that main does NOT return directly to the
>> environment but through another function called exit. I suppose we could
>> overload exit():
>>
>> int exit();
>> int exit(int);
>>
>> Or even make the declaration of exit:
>>
>> int exit(int=1);
>>
>> Perhaps the latter is the right way to go in the process of evolving C++
>> to be more intuitive.

Some direction like this seems reasonable probably.

>Are you sure that you are not thinking about C?

Well, it could apply to C too, since IMO, main's messed up there too.

>AFAIK, the C++ runtime
>code that happens before and after "main" can be any code, as long as it
>does program setup/breakdown correctly.  It doesn't have to involve
>"exit" at all, or only as a part.

It must usually involve exit().  I don't recall that abort() has to
call exit() though, so that may or may not have to be another issue
to deal with.

>I thought "exit" would only handle
>the C-specific stuff.  For an environment that doesn't use program
>return values, the return value of "exit" is superflous.

True, but that doesn't have anything to do with C or C++ handling
things different if I understand you.
--
Greg Comeau         export ETA: December     See our Oct 31st special
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <1f2pq7v.108pih51lyhp22N%dwalker07@snet.net.invalid>,
Daryle Walker <dwalker07@snet.net.invalid> wrote:
>James Kuyper Jr. <kuyper@wizard.net> wrote:
>> Daryle Walker wrote:
>> > AFAIK, the only caller of "main" is the C++ runtime.  Unlike C, the
>> > environment can't call "main" directly from the outside, and there can
>>
>> I'm not sure what you mean by that. Could you give an example of "the
>> environment" calling '"main" directly from the outside'? The only thing
>> I can think of that would qualify is some kind of debugger, but in that
>> it's no different from C++.
>
>In C, there is no behind-the-scences set-up to be done, so the linker
>can arrange the executable so the environment calls the program by
>calling main directly.  In C++, there has to be background set-up to
>handle global constructors, exception handling, etc.; I call this the
>C++ runtime code.  The linker arranges the environment to call the
>runtime intialization function first instead.  The "main" function gets
>called by the runtime code, and not by the environment directly.

Although what you say can be the case, and often it, it's mostly
really just implementation details,  Both languages allow leeway
here. So, for instance, there may be behind the scenes things in C,
or there may not be (in a particular piece of code for instance) for C++.
And so on.  Furthermore, the are different techniques to accomplish
the requirements of both languages.

>> > be no other callers of "main" on the inside, not even itself.  (I think
>> > old versions of C allowed other functions to call "main," even itself
>> > recursively.) ...
>>
>> Current versions, too.
>[TRUNCATE]
>
>OK.  I guess C still doesn't have any behind-the-scences set-up, so
>"main" can be treated like an ordinary function.

Normally that's the common situation, but C has no such requirement
that this be so, at least as far as I recall.  As above, I think we
need to be cautious as to what is a common implementation vs what
the respective standards actually allow or not.
--
Greg Comeau         export ETA: December     See our Oct 31st special
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Daryle Walker wrote:
>
> I read a lot of corrections in the various C++ newsgroups that suggest
> changing "void main()" declarations to "int main()".  This is because
> standard C++ only allows an "int" return.  This probably came from
> Unix-based C and C++, which passed the return value of "main" to the
> environment.  However, other enviroments (Mac, maybe Windows) have no
> use for a return value.  This leads to C++ writers of those environments
> to use "void main()", which leads to the compilants I initially
> mentioned.
>

It's bad enough that main is inversely overloaded (it's the only function
where you provide one definition that and the caller has to resolve which
of the legal variants of the function the user actually provided).  Further
kludging it up seems pointless.

You are right, the allowance of omitting the return value in main is inane.
It actually has nothing to do with the MAC, the reason is hilarious (compatibility
with a long ago written snippet of C code which doesn't compile anymore in
the current standard versions of either C or C++).

I don't see how furhter kluding of main helps anything.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <1f27z3z.1603cnt1s8z81mN%darylew@mac.com>,
Daryle Walker <darylew@mac.com> wrote:
>I read a lot of corrections in the various C++ newsgroups that suggest
>changing "void main()" declarations to "int main()".  This is because
>standard C++ only allows an "int" return.

At least in hosted environments, right.

>This probably came from
>Unix-based C and C++, which passed the return value of "main" to the
>environment.

Ok.

>However, other enviroments (Mac, maybe Windows) have no
>use for a return value.  This leads to C++ writers of those environments
>to use "void main()", which leads to the compilants I initially
>mentioned.

Well, they could still use int main(), even if the int didn't go
anywhere (I'm not arguing either way, just pointing out that
void main doesn't have to be a requirement for such an environment,
despite it being odd that there is no where to pass the int).

>This has resulted in a wierd compromise in the C++ standard: "main"
>still has to return "int," but a return declaration can be ommitted,
>like in void-returning functions (and if the return is omitted the
>function acts like a "return 0" is at its end).

If you mean the above has led to this, then no, I disagree.
But of course, that doesn't make the situation any less weird.

>This lets a
>void-main-user transition to the standard way by just changing the
>return type of "main."  Unfortunately, it makes C++ grammar irregular
>(since all function definitions must have a return policy that conforms
>to the return type, except "main").

Well, some argue it should conforms too.

>I think this "solution" was a silly (IMHO) way to go.  The int-only guys
>desired the int-only rule so much that they agreed to bend the grammar
>to give the void-likers a back door?  I think the int-only guys should
>have conceded that not all environments demand a return value.  If we
>could allow "main" not to require "argc" and "argv," we can give up on
>the int-only return feature too.

main has other problems besides this, so perhaps it will get
revisited in C++0x.

>Maybe it can be like:
>
>//=====================================================================
>On hosted implementations, the main function has one of these
>signatures:
>
>    XX main( );
>    XX main( int argc, char *argv[] );
>
>(where "XX" is explained later).  It can also have signatures that match
>the second, but with implementation-specified arguments after the two
>arguments given here.  The return type "XX" can be:
>
>    int
>    void
>    std::main_t  (defined in <cstddef>)

Don't forget std::string's and stuff like that then.
--
Greg Comeau         export ETA: December     See our Oct 31st special
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

I read a lot of corrections in the various C++ newsgroups that suggest
changing "void main()" declarations to "int main()".  This is because
standard C++ only allows an "int" return.  This probably came from
Unix-based C and C++, which passed the return value of "main" to the
environment.  However, other enviroments (Mac, maybe Windows) have no
use for a return value.  This leads to C++ writers of those environments
to use "void main()", which leads to the compilants I initially
mentioned.

This has resulted in a wierd compromise in the C++ standard: "main"
still has to return "int," but a return declaration can be ommitted,
like in void-returning functions (and if the return is omitted the
function acts like a "return 0" is at its end).  This lets a
void-main-user transition to the standard way by just changing the
return type of "main."  Unfortunately, it makes C++ grammar irregular
(since all function definitions must have a return policy that conforms
to the return type, except "main").

I think this "solution" was a silly (IMHO) way to go.  The int-only guys
desired the int-only rule so much that they agreed to bend the grammar
to give the void-likers a back door?  I think the int-only guys should
have conceded that not all environments demand a return value.  If we
could allow "main" not to require "argc" and "argv," we can give up on
the int-only return feature too.

Maybe it can be like:

//=====================================================================
On hosted implementations, the main function has one of these
signatures:

    XX main( );
    XX main( int argc, char *argv[] );

(where "XX" is explained later).  It can also have signatures that match
the second, but with implementation-specified arguments after the two
arguments given here.  The return type "XX" can be:

    int
    void
    std::main_t  (defined in <cstddef>)

Where "std::main_t" is the return type that may be optimal for the host
enviroment.  (This new type may be a typedef of "int" or "void," or
maybe another built-in type, or an environment-defined structure.)  The
policies mixing these return types with environments is:

* If the environment doesn't use program return types, then
"std::main_t" is "void" and nothing special happens if those types are
used as the main return value.  It "int" is used, that return value goes
to oblivion.

* If the environment program return type is "int," then "std::main_t" is
"int" and if "main" has one of those return types, the return value is
passed to the environment.  If "main" uses a "void" return, then the
system acts if a "return 0;" was used.

* If neither "int" nor "void" is the environment program return type,
then "std::main_t", defined in <cstddef>, is a typedef and/or structure
of the appropiate type.  The implementation shall define (and document)
how a "main" that uses "int" or "void" handles the return value
conversion.
//=====================================================================

Since this just adds new "main" configurations, it should be
backwards-compatible with the current rule.  The main (ugh) problem
would be how to resolve the current "implicit return 0" solution.

--
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <1f27z3z.1603cnt1s8z81mN%darylew@mac.com>, Daryle Walker
<darylew@mac.com> writes
>I think this "solution" was a silly (IMHO) way to go.  The int-only guys
>desired the int-only rule so much that they agreed to bend the grammar
>to give the void-likers a back door?  I think the int-only guys should
>have conceded that not all environments demand a return value.  If we
>could allow "main" not to require "argc" and "argv," we can give up on
>the int-only return feature too.

That may be, but all programs can be used in contexts where a return
value IS required unless they are being executed in a free standing
environment. Personally I would have preferred that main had not been
special cased to allow omitting the return statement.

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]