C++Talk.NET Forum Index C++Talk.NET
C++ language newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Proposal: finally allow "void main()"
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ language, library and standards
View previous topic :: View next topic  
Author Message
Daryle Walker
Guest





PostPosted: Sun Mar 13, 2005 5:54 am    Post subject: Proposal: finally allow "void main()" Reply with quote



Declaring a program's "main" function to have a "void" return type is a
favorite of many, especially newbies. It supposed to acknowledge that
either the environment doesn't use return codes, or that the user
doesn't care (and the runtime should provide a default). Since the
standard is supposed to reflect established practice, let's finally put
this in.

1. In section 3.6.1 [basic.start.main], change paragraph 2 and
associated code to:

//==========================================
An implementation shall not predefine the main function. This function
shall not be overloaded. It shall have a return type of either type
int, type void, or type bool, but otherwise its type is
implementation-defined. All implementations shall allow the following
six definitions of main:

int main() { /* ... */ }
void main() { /* ... */ }
bool main() { /* ... */ }
int main(int argc, char* argv[]) { /* ... */ }
void main(int argc, char* argv[]) { /* ... */ }
bool main(int argc, char* argv[]) { /* ... */ }

In the latter three forms argc shall be the number of arguments passed
to the program from the environment in which the program is run. If
argc is nonzero these arguments shall be supplied in argv[0] through
argv[argc-1] as pointers to the initial characters of null-terminated
multibyte strings (NTMBSs) (17.3.2.1.3.2) and argv[0] shall be the
pointer to the initial character of a NTMBS that represents the name
used to invoke the program or "". The value of argc shall be
nonnegative. The value of argv[argc] shall be 0. [Note: it is
recommended that any further (optional) parameters be added after argv.
]
//==========================================

2. Change paragraph 5 and associated code of the same section to:

//==========================================
For a main function with a return type of type int, a return statement
within that function has the effect of leaving that function (destroying
any object with automatic storage duration) and calling exit with the
return value as the argument. If control reaches the end of main
without encountering a return statement, the effect is that of executing

return 0;

For a main function with a return type of type void, when the flow of
the function's control ends, with or without a return statement, it
shall have the same effect as if it was a main function with a return
type of int that returns a value of zero. For a main function with a
return type of type bool, a return statement with its expression
evaluating to true shall have the same effect as if it was a main
function with a return type of int that returns a value of zero. If the
expression evaluates to false instead, then the return has the same
effect as if it was a main function with a return type of int that
returns an implementation-specified non-zero value. If the control of
such a function ends without encountering a return statement, it shall
act as if it ended with a return statement with a return value of true.
//==========================================

(Yeah, I added a third type there [bool]. I was looking at old posts
and saw the idea. I thought it was a good idea, so I snuck it in.)

--
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.jamesd.demon.co.uk/csc/faq.html ]

Back to top
Michael Etscheid
Guest





PostPosted: Sun Mar 13, 2005 7:29 pm    Post subject: Re: Proposal: finally allow "void main()" Reply with quote



Daryle Walker schrieb:
Quote:
[proposal that bool main() is allowed]

Why do you want to standardize bool main()? It's neither widespread nor
does it allow to do something what you cannot do with int main().

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


Back to top
Alf P. Steinbach
Guest





PostPosted: Mon Mar 14, 2005 7:05 pm    Post subject: Re: Proposal: finally allow "void main()" Reply with quote



* Daryle Walker:
Quote:
[Proposing bool and void return types, that I disagree with!]

I think the proposal as-is only solves the problem of "C++ 'main'
for the utter newbie", which the language isn't designed for anyway.

Plus, how should we identify the utter newbies if 'void' was allowed?

On the other hand, I agree with my own observation that the
functionality that 'main' offers is long (about 25 years) overdue
for an update, because

* 'main' is a _system specific_ and _locale specific_ function,
designed exclusively for an English language 1970's Unix; it's
a less than useful anachronism in modern C++.

Consider:

* It does not support wide character arguments, hence, not
Norwegian filenames (yes, they can theoretically be supported
via multi-byte encoding, no, we don't live in FairyWorld).

* It does not support Windows command lines. Since Windows does
not natively support quoting like Unix does command lines that
contain spaces are a problem with the current 'main'. I think
there are now _enough_ programs that don't support paths with
spaces in 'em (Windows standard directories have such paths).

* It requires delving down to the level of raw pointers and arrays,
which is not safe and means the newbie either has to do without
command line arguments, or use very unsafe constructs, or
use some library (and installing and using a C++ library is not
exactly easy for the newbie).

Hence I propose a standard library solution to this mess, so that we can
write

#include <iostream>
#include <environment>

int main()
{
std::environment env; // A std::environment_<char>.

std::cout << env.command_line() << std::endl;
for( std::size_t i = 0; i < env.args.size(); ++i )
{
std::cout << i << ": " << env.args().at( i ) << std::endl;
}
}

where for e.g. Unix command_line() is synthesized, whereas for Windows
args() is synthesized, some vague rules are in place for what constitutes an
argument (good enough, not perfect), and a means to check what is synthesized
and what is not is provided. I imagine std::environment to be a kind of
accessor class for a read-only environment (some implementations in other
languages provide a means to change the current directory, but in C++ we
don't have directories...). As such constructor arguments could specify
how to e.g. break a Windows command line up into arguments, or how to
synthesize a command line from individual Unix arguments; for those who are
not familiar with this most basic of the basics (I know there are some, after
earlier discussions in clc++m), a Windows command line is _not_ exactly what
the user types in a command interpreter, but is a line of text passed to the
API function that creates the process, and for a command interpreter command
that's the user command sans redirections and some meta-symbols; hence there's
not that big a difference between a syntehesized one and the real thing, in
that neither is an exact copy of what a user types to start a program.

In addition to safe standard library class based information a
std::environment class should offer the C-style 'main' arguments plus wide
character versions of them, because that's required by many libraries.

Something complicated like the options parser in Boost = UnGood.

The example code above of course assuming that current practice.


PS: Yes, I know this is nowhere near being a Proposal. It needs some details
added, such as a proposed text for the standard... But that, if I or
someone does that, will hopefully be after discussion, e.g. here.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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


Back to top
Ron Natalie
Guest





PostPosted: Mon Mar 14, 2005 7:05 pm    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

Daryle Walker wrote:
Quote:
Declaring a program's "main" function to have a "void" return type is a
favorite of many, especially newbies. It supposed to acknowledge that
either the environment doesn't use return codes, or that the user
doesn't care (and the runtime should provide a default). Since the
standard is supposed to reflect established practice, let's finally put
this in.

I think the proposal that "people improperly use this construct" is a stupid

reason to add a feature to the language. It's exactly this sort of stupidity
that codified the "main is special in that you're allowed not to return a
value". I'd support your idea only if we forbid falling off the end of
the non-void main :-)

Quote:
(Yeah, I added a third type there [bool]. I was looking at old posts
and saw the idea. I thought it was a good idea, so I snuck it in.)

And what use would it be? Are you planning to take every function that
treats takes int and adds a bool option? Why not just get rid of this
clunky leftover from C-in-UNIX-land-defines-C++-forever and consider
main types of the form:

std::string main(std::string)

etc... which is closer to what many native environments want to invoke
programs with anyhow.

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


Back to top
Francis Glassborow
Guest





PostPosted: Mon Mar 14, 2005 7:05 pm    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

In article <1gt9s1a.1ltk36qdkqctcN%thedl0-usenet1 (AT) yahoo (DOT) com>, Daryle
Walker <thedl0-usenet1 (AT) yahoo (DOT) com> writes
Quote:
Declaring a program's "main" function to have a "void" return type is a
favorite of many, especially newbies. It supposed to acknowledge that
either the environment doesn't use return codes, or that the user
doesn't care (and the runtime should provide a default). Since the
standard is supposed to reflect established practice, let's finally put
this in.

I see, because a large number of authors of books for novices + a couple
of implementation provided extensions allow something we should put it
in the Standard. Now when the novice gets a bit further they will
discover that main() exits by 'calling' exit(int). We now have to
explain where the int value comes from (OK, in C++ we could make it a
default argument).

Now think of the effect of your proposed change. It buys no extra
functionality. It costs every implementer by making them handle the
extra signatures. It only benefits ignorant programmers (and removes one
of the criteria for identifying ignorant authors). Overall that seems to
me to be a modicum of cost with no real benefit.

Please note that I am greatly in favour of removing genuine warts from
the language but would prefer to focus on those.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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


Back to top
Victor Bazarov
Guest





PostPosted: Mon Mar 14, 2005 7:05 pm    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

"Daryle Walker" <thedl0-usenet1 (AT) yahoo (DOT) com> wrote...
Quote:
Declaring a program's "main" function to have a "void" return type is a
favorite of many, especially newbies. [...]

But so are null references. You don't see anybody proposing changing the
language to accommodate them, do you?


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


Back to top
Trevor L. Jackson, III
Guest





PostPosted: Mon Mar 14, 2005 7:05 pm    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

Daryle Walker wrote:

Quote:
Declaring a program's "main" function to have a "void" return type is a
favorite of many, especially newbies. It supposed to acknowledge that
either the environment doesn't use return codes, or that the user
doesn't care (and the runtime should provide a default). Since the
standard is supposed to reflect established practice, let's finally put
this in.

1. In section 3.6.1 [basic.start.main], change paragraph 2 and
associated code to:

//==========================================
An implementation shall not predefine the main function. This function
shall not be overloaded. It shall have a return type of either type
int, type void, or type bool, but otherwise its type is
implementation-defined. All implementations shall allow the following
six definitions of main:

int main() { /* ... */ }
void main() { /* ... */ }
bool main() { /* ... */ }
int main(int argc, char* argv[]) { /* ... */ }
void main(int argc, char* argv[]) { /* ... */ }
bool main(int argc, char* argv[]) { /* ... */ }

In the latter three forms argc shall be the number of arguments passed
to the program from the environment in which the program is run. If
argc is nonzero these arguments shall be supplied in argv[0] through
argv[argc-1] as pointers to the initial characters of null-terminated
multibyte strings (NTMBSs) (17.3.2.1.3.2) and argv[0] shall be the
pointer to the initial character of a NTMBS that represents the name
used to invoke the program or "". The value of argc shall be
nonnegative. The value of argv[argc] shall be 0. [Note: it is
recommended that any further (optional) parameters be added after argv.
]
//==========================================

2. Change paragraph 5 and associated code of the same section to:

//==========================================
For a main function with a return type of type int, a return statement
within that function has the effect of leaving that function (destroying
any object with automatic storage duration) and calling exit with the
return value as the argument. If control reaches the end of main
without encountering a return statement, the effect is that of executing

return 0;

For a main function with a return type of type void, when the flow of
the function's control ends, with or without a return statement, it
shall have the same effect as if it was a main function with a return
type of int that returns a value of zero. For a main function with a
return type of type bool, a return statement with its expression
evaluating to true shall have the same effect as if it was a main
function with a return type of int that returns a value of zero. If the
expression evaluates to false instead, then the return has the same
effect as if it was a main function with a return type of int that
returns an implementation-specified non-zero value. If the control of
such a function ends without encountering a return statement, it shall
act as if it ended with a return statement with a return value of true.
//==========================================

(Yeah, I added a third type there [bool]. I was looking at old posts
and saw the idea. I thought it was a good idea, so I snuck it in.)

I think it is an interesting idea, but I also think you got the polarity
backwards. Since zero is always false returning zero should have the
same meaning as returning false and vice versa.

Since we choose opposite interpretations for the "natural" meaning of
bool, maybe including it isn't sucha good idea.

But void main() is a necessity. I will not use a compiler that does not
support the common, classic feature. It was once standard and there can
be no rationale for deprecating it. So it should stll be standard. In
practice it is and the official standard should recognize that as a fact
(Is there a member of the Committee named Canute?)

/tj3

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


Back to top
Jack Klein
Guest





PostPosted: Mon Mar 14, 2005 7:05 pm    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

On Sun, 13 Mar 2005 05:54:41 GMT, [email]thedl0-usenet1 (AT) yahoo (DOT) com[/email] (Daryle
Walker) wrote in comp.std.c++:

Quote:
Declaring a program's "main" function to have a "void" return type is a
favorite of many, especially newbies. It supposed to acknowledge that

Another favorite of newbies, and too many not-so-newbies, it storing
data via uninitialized pointers. Should we make this work as well?

Quote:
either the environment doesn't use return codes, or that the user
doesn't care (and the runtime should provide a default). Since the
standard is supposed to reflect established practice, let's finally put
this in.

1. In section 3.6.1 [basic.start.main], change paragraph 2 and
associated code to:

//==========================================
An implementation shall not predefine the main function. This function
shall not be overloaded. It shall have a return type of either type
int, type void, or type bool, but otherwise its type is
implementation-defined. All implementations shall allow the following
six definitions of main:

int main() { /* ... */ }
void main() { /* ... */ }
bool main() { /* ... */ }
int main(int argc, char* argv[]) { /* ... */ }
void main(int argc, char* argv[]) { /* ... */ }
bool main(int argc, char* argv[]) { /* ... */ }

[snip]

I am very much against this. First of all, it requires triple the
number of required forms that every single conforming implementation
would need to support, for no gain at all. And as another poster has
pointed out, there is nothing that a bool return from main() can
accomplish that isn't already possible with an int return.

Note that every implementation is allowed to reject "void main()" with
whatever diagnostic it might like, and some do.

If you insist that some sort of semi-standard blessing be bestowed on
"void main()" -- and I disagree -- there is certainly no need to
mandate it. You can always throw in weasel words like C99 does:

[begin quotation]
The function called at program startup is named main. The
implementation declares no prototype for this function. It shall be
defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared):
int main(int argc, char *argv[]) { /* ... */ }

or equivalent; or in some other implementation-defined manner.
[end quotation]

This would be only a minor modification to the C++ standard. The
second sentence of 3.6.1 para 2 would need to go away, the the "in
some other implementation-defined manner" moved to the end.

I am not thrilled with the rationale espoused for this in comp.std.c,
and would rather it had not been added to the C standard. But even if
such weaseling were added to the C++ standard, *requiring*
implementations to support other than the two canonical forms is just
plain wrong.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

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


Back to top
Francis Glassborow
Guest





PostPosted: Mon Mar 14, 2005 8:16 pm    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

In article <7eednd9CWOZfda7fRVn-qQ (AT) comcast (DOT) com>, "Trevor L. Jackson,
III" <tlj3 (AT) comcast (DOT) net> writes
Quote:
But void main() is a necessity. I will not use a compiler that does
not support the common, classic feature. It was once standard and
there can be no rationale for deprecating it. So it should stll be
standard. In practice it is and the official standard should recognize
that as a fact (Is there a member of the Committee named Canute?)

When was it Standard in either C or C++? Note that main returns to
exit() which requires an int argument so either the programmer must
provide one or the implementation must hack one in.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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


Back to top
ThosRTanner
Guest





PostPosted: Tue Mar 15, 2005 12:20 am    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

I would imagine he wants a bool main, because there are only 2 values
which are defined for the return from main - EXIT_SUCCESS (which
indicates succesful termination), and EXIT_FAILURE (which doesn't).
The effect of returning other values is undefined, and returning (e.g.)
0xffff0000 might indicate success on some systems and fairlure on
others.

I think I'd rather have a 2 value enumeration
typedef enum { Success, Failure } Exit_Status;

Exit_Status main() { ... }

on the basis that it is generally a bad idea to return or pass true or
false - there is a lot of semantic information that can be supplied
with a 2 value enumeration which gets lost if you use a bool. It is
also slightly counter-intuitive that "return true" means completely the
opposite to "return 1".

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

Back to top
Trevor L. Jackson, III
Guest





PostPosted: Tue Mar 15, 2005 12:33 am    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

Ron Natalie wrote:

Quote:
I'd support your idea only if we forbid falling off the end of
the non-void main Smile

I like that idea. Falling off the end of a non-main(), non-void
function is an error. And main() should live within that same rule.

/tj3

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


Back to top
Trevor L. Jackson, III
Guest





PostPosted: Tue Mar 15, 2005 12:36 am    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

Victor Bazarov wrote:

Quote:
"Daryle Walker" <thedl0-usenet1 (AT) yahoo (DOT) com> wrote...

Declaring a program's "main" function to have a "void" return type is a
favorite of many, especially newbies. [...]


But so are null references. You don't see anybody proposing changing the
language to accommodate them, do you?

Yes. The value of C++ references is that they can;t be NULL. had the
language not been changed to accomodate the error-prone nature of raw
pointers we would still be living with a high incidence of NULL values
in pointers that shouldn;t even have that value.

Case in point: The pseudo variable "this" is a pointer. Everyone
knows it should be a reference. and everyone also knows that given that
it is a pointer rather than a reference it should be const. But it
isn't and we are stuck with it.

void main() has been around for decades and there is no reason not to
standardize the prevailing practice.

/tj3

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


Back to top
Trevor L. Jackson, III
Guest





PostPosted: Tue Mar 15, 2005 12:45 am    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

Jack Klein wrote:

Quote:
On Sun, 13 Mar 2005 05:54:41 GMT, [email]thedl0-usenet1 (AT) yahoo (DOT) com[/email] (Daryle
Walker) wrote in comp.std.c++:


Declaring a program's "main" function to have a "void" return type is a
favorite of many, especially newbies. It supposed to acknowledge that


Another favorite of newbies, and too many not-so-newbies, it storing
data via uninitialized pointers. Should we make this work as well?


either the environment doesn't use return codes, or that the user
doesn't care (and the runtime should provide a default). Since the
standard is supposed to reflect established practice, let's finally put
this in.

1. In section 3.6.1 [basic.start.main], change paragraph 2 and
associated code to:

//==========================================
An implementation shall not predefine the main function. This function
shall not be overloaded. It shall have a return type of either type
int, type void, or type bool, but otherwise its type is
implementation-defined. All implementations shall allow the following
six definitions of main:

int main() { /* ... */ }
void main() { /* ... */ }
bool main() { /* ... */ }
int main(int argc, char* argv[]) { /* ... */ }
void main(int argc, char* argv[]) { /* ... */ }
bool main(int argc, char* argv[]) { /* ... */ }


[snip]

I am very much against this. First of all, it requires triple the
number of required forms that every single conforming implementation
would need to support, for no gain at all.

Please support your contention that there is no gain at all. I dispute
it. You may not be aware of any possible gain, but that's not what you
said. Can you prove that there is no possible gain?


Quote:
And as another poster has
pointed out, there is nothing that a bool return from main() can
accomplish that isn't already possible with an int return.

Agreed. However, there are several things a floating point result might
encompass that int main() cannot.

Quote:

Note that every implementation is allowed to reject "void main()" with
whatever diagnostic it might like, and some do.

Right. And that problem can be fixed.

Quote:

If you insist that some sort of semi-standard blessing be bestowed on
"void main()" -- and I disagree -- there is certainly no need to
mandate it. You can always throw in weasel words like C99 does:

[begin quotation]
The function called at program startup is named main. The
implementation declares no prototype for this function. It shall be
defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared):
int main(int argc, char *argv[]) { /* ... */ }

or equivalent; or in some other implementation-defined manner.
[end quotation]

This would be only a minor modification to the C++ standard. The
second sentence of 3.6.1 para 2 would need to go away, the the "in
some other implementation-defined manner" moved to the end.

I am not thrilled with the rationale espoused for this in comp.std.c,
and would rather it had not been added to the C standard. But even if
such weaseling were added to the C++ standard, *requiring*
implementations to support other than the two canonical forms is just
plain wrong.

Agreed. The argument-less forms should be eliminated.

/tj3


Quote:


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


Back to top
Victor Bazarov
Guest





PostPosted: Tue Mar 15, 2005 4:20 am    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

"Trevor L. Jackson, III" <tlj3 (AT) comcast (DOT) net> wrote...
Quote:
[...]
void main() has been around for decades and there is no reason not to
standardize the prevailing practice.

How is it prevailing? And it is not enough a reason to standardize it
only because it has been around. Curse words have been around for ages
and yet in polite society they are carefully avoided.


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


Back to top
Ron House
Guest





PostPosted: Tue Mar 15, 2005 4:21 am    Post subject: Re: Proposal: finally allow "void main()" Reply with quote

Trevor L. Jackson, III wrote:

Quote:
void main() has been around for decades and there is no reason not to
standardize the prevailing practice.

So have so many rotten system utilities that don't return sane result
statuses, making script control hopeless; and "void main" in the
compilers those programmers are using is the likely culprit. main should
return int, and it should be an error to omit the return.

--
Ron House [email]house (AT) usq (DOT) edu.au[/email]
http://www.sci.usq.edu.au/staff/house

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


Back to top
Display posts from previous:   
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.