Topic: Proposal: finally allow "void main()
Author: alfps@start.no (Alf P. Steinbach)
Date: Mon, 4 Apr 2005 12:55:01 GMT Raw View
[
Reposted, 3rd time (+ original posting).
Original posting was received in mod q but then did not appear, not rejected,
not accepted, while other postings have continued.
And the same happened with the 1st re-post: received in q, nothing further.
And the same happened with the 2nd re-post: received in q, nothing further.
]
* "Bronek Kozicki":
> Alf P. Steinbach <alfps@start.no> wrote:
> > * 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).
>
> This is good point. However, I suppose that decent support for unicode
> (there is ISO standard for that, after all) in the C++ standard would
> provide good foundation to solve this problem. And I do not agree that
> wchar_t alone is "good enough" support for unicode.
Not sure whom you're disagreeing with since I didn't mention Unicode.
I agree that Unicode support would be Nice To Have, in general.
But as long as C++ doesn't support Unicode it would be very unreasonable to
require 'main' to support Unicode.
> > * 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).
>
> I will discuss it below.
I'm unable to find that discussion.
> > * 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).
>
> standard C++ library should be installed with C++ compiler, and if it is
> not, then said newbie should just look for better compiler or
> programming environment. If standard C++ library is available, then safe
> use of command line arguments is just one line of code that's very easy
> to understand and memorize:
>
> int main(int argc, char* argv[])
> {
> std::vector<std::string> args(argv, argv + argc);
> // ... use args instead of argc/argv
> }
I suppose this can be used as a _magic incantation_.
But the point still stands.
I wrote what I wrote fully aware of the above construction
(see e.g. <url:
http://groups.google.no/groups?threadm=420b08ca.586968296%40news.individual.net>).
> .. and if said newbie does not understand this code, maybe he/she
> should just start learning C++ from some real handbook (like Koenig &
> Moo).
Presumably you mean Accelerated C++; that's good advice but I do not see
any connection to the issues discussed here, and I think Accelerated C++
deserves better than to be called a "handbook".
> > Hence I propose a standard library solution to this mess, so that we
> > can write
>
> standard library solution might be good idea for internationalization
> and parsing of command line arguments, however ...
>
>
> > where for e.g. Unix command_line() is synthesized, whereas for Windows
> > args() is synthesized, some vague rules are in place for what
>
> .. what names "Windows" or "Unix" do here is beyond my comprehension.
> C++ is OS neutral, and making some assumptions as to behaviour of
> standard library depending on particular platform is very inapropriate,
> IMHO. I hope that C++ is bound to live longer than limitations of said
> platforms (or specific command processors or file systems).
This is incomprehensible to me; perhaps you could elaborate on how an
effort to remove this platform-dependency is in conflict with your ideal?
--
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 ]
Author: thedl0-usenet1@yahoo.com (Daryle Walker)
Date: Sun, 13 Mar 2005 05:54:41 GMT Raw View
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 ]
Author: Michael Etscheid <the.michael.e@gmail.com>
Date: Sun, 13 Mar 2005 13:29:33 CST Raw View
Daryle Walker schrieb:
> [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 ]
Author: alfps@start.no (Alf P. Steinbach)
Date: Wed, 16 Mar 2005 16:01:55 CST Raw View
* Ben Hutchings:
> Alf P. Steinbach wrote:
> > * Daryle Walker:
> >> [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).
>
> What do you mean, theoretically? AFAIK Norwegian text can be written
> entirely in ISO 8859-1 (single-byte) and certainly it can be written
> in UTF-8, which is what I have been using as my default text encoding
> for a while now. Only a few programs have trouble with UTF-8.
"Theoretically" means that it's ungood as practice.
How do you know what encoding is used, if it's different from the default
encoding otherwise employed?
You don't, not in any portable way, and passing those arguments around
will then just result in gibberish.
> Actually Windows *does* natively support quoting and escaping. See
> the CommandLineToArgvW function.
I'm familiar with that function and do not see the relevance, even after
consulting the technical documentation.
Correct me if I'm wrong but I think the above is a response to my statement
that "Windows does not natively support quoting like Unix does".
As an example of what I referred to, try to write an 'echo' command for
Unix in standard C++ (C++ supports this). Then try the same for Windows
(C++ does not support this, the language is OS-specific). Imagine that that
'echo' command is e.g. a perl interpreter.
> The VC++ implementations of the exec* and spawn* families of functions
> do not apply necessary quoting and escaping, but that's another matter
> entirely.
It is entirely another matter what goes on inside the run-time library
before the arguments reach 'main', yes.
Nothing that goes on there can make up for the fact that C++ 'main' is
Unix-oriented, and that that's a _fundamentally_ different model from
the one employed in Windows.
In very many cases one can be emulated in terms of the other, and
that's part of what I propose; in some cases, when accuracy is called
for, one needs to have the "original" information, and so that's also
part of what I propose.
>
> > * 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).
>
> This I can agree with.
>
> > 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,
> <snip>
>
> What is the point of this? Are there really any OSs that don't have
> any conventions for conversion between command lines and lists of
> arguments? (There must always be at least some rule for extracting
> the command name.)
Hm, I've mentioned Windows, isn't that a good enough example?
As a very example, consider two programs with conflicting requirements.
In program A you want to support filenames with possible multiple, contigous
spaces. In program B you want to support embedded quotes in arguments, e.g.
program B can be an interpreter for some script language.
The C++ 'main' supports both A and B under Unix, because C++ 'main' conforms
to the Unix argument passing model, but not under Windows.
--
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 ]
Author: ron@sensor.com (Ron Natalie)
Date: Wed, 16 Mar 2005 22:03:52 GMT Raw View
ThosRTanner wrote:
> Jack Klein wrote:
> [snip]
>
>>... 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.
>
>
> There is a good argument for a bool or an enumeration being returned,
> in that if an int is anything other than EXIT_FAILURE or EXIT_SUCCESS,
> what is returned to the caller is implementation specific. And, yes, I
> have seen cases where main has returned a number that on one system
> indicates an error to the caller, and on another returns success.
>
What is returned to the caller IS ALWAYS IMPLEMENTATION SPECIFIC.
C++ has no definition on how status is returned to other programs.
The only thing returning 0, EXIT_SUCCESS, or EXIT_FAILURE is tell
you that you are returning one of the implementation defined SUCCESS
or FAILURE values (as appropritate). In fact, the implementation
may not be able to do anything with the return value of main/exit.
Some systems return a value of some size (traditional UNIX reserves
most of a char for this), some systems have two different exit
system calls, one for error and one for normal exit.
---
[ 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 ]
Author: John Nagle <nagle@animats.com>
Date: Wed, 16 Mar 2005 16:01:53 CST Raw View
Daryle Walker wrote:
> 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.
Arguably, the "main" convention shouldn't be part of the
language at all. It's an operating system interface, and
varies with the OS. Windows, for one, uses WinMain.
"int main(int argc, const char* argv[])" is a standard UNIX
interface, and should be declared, but not defined,
in <unistd.h>. Interface control for that belongs to POSIX,
not the C++ committee.
Liasion with POSIX to standardize a wide-character form
of that interface would be productive.
John Nagle
Animats
---
[ 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 ]
Author: alfps@start.no (Alf P. Steinbach)
Date: Wed, 16 Mar 2005 16:49:54 CST Raw View
* John Nagle:
> Daryle Walker wrote:
>
> > 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.
>
> Arguably, the "main" convention shouldn't be part of the
> language at all.
Agreed, if we're talking about the hypothetical what-could-have-been.
> It's an operating system interface, and
> varies with the OS.
Yep.
>Windows, for one, uses WinMain.
Sorry, that's incorrect (I hope the moderators allow such a correction
of fact even though it's off-topic: having correct facts is IMO important).
It is however so common a misconception that even the Microsoft technical
writers have stated the same in the documentation -- contradicting both
reality and the more accurate original parts of that same documentation.
On the other hand, Microsoft's C++ compiler is out-of-the-box non-conforming
wrt. to many language features (standard library header files will not compile
cleanly), and many or most programmers aren't aware that it can be configured
to compile standard C++ also wrt. 'main', i.e. using a standard 'main'.
Internally there is then no 'WinMain'. There's just an entry point which is
less than well-documented but is definitely not 'WinMain'-like (in passing,
I wonder where compiler writers get such information, e.g. to implement my
suggested std::environment class one would need to pick up Unix arguments
in the same way as the entry point of a Unix program, is that documented?).
> "int main(int argc, const char* argv[])" is a standard UNIX
> interface, and should be declared, but not defined,
> in <unistd.h>. Interface control for that belongs to POSIX,
> not the C++ committee.
Ideally, yes, agreed, but removing it from the language would break almost all
code in existence (excluding non-conforming WinMain & friends, and embedded).
> Liasion with POSIX to standardize a wide-character form
> of that interface would be productive.
I didn't think of that but that sounds like a very good idea. :-)
--
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 ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: Thu, 17 Mar 2005 13:50:06 CST Raw View
===================================== MODERATOR'S COMMENT:
Warning: severe topic drift off the starboard bow, cap'n!
===================================== END OF MODERATOR'S COMMENT
"Alf P. Steinbach" <alfps@start.no> wrote in message
news:4238b008.857273781@news.individual.net...
> On the other hand, Microsoft's C++ compiler is out-of-the-box
> non-conforming
> wrt. to many language features (standard library header files will not
> compile
> cleanly),
Beg pardon? V6.0 produces *warnings* if you crank the compiler up to
a certain level; but it froze years before the C++ Standard settled
down anyway. I believe that V7.1 is the most conforming C++ library
on the market today. So I don't understand what you mean with this
statement.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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.jamesd.demon.co.uk/csc/faq.html ]
Author: alfps@start.no (Alf P. Steinbach)
Date: Thu, 17 Mar 2005 14:20:53 CST Raw View
* P.J. Plauger:
>
> ===================================== MODERATOR'S COMMENT:
> Warning: severe topic drift off the starboard bow, cap'n!
>
>
> ===================================== END OF MODERATOR'S COMMENT
If the moderators allow, I'll answer the factual of PJ's question.
> "Alf P. Steinbach" <alfps@start.no> wrote in message
> news:4238b008.857273781@news.individual.net...
>
> > On the other hand, Microsoft's C++ compiler is out-of-the-box
> > non-conforming
> > wrt. to many language features (standard library header files will not
> > compile
> > cleanly),
>
> Beg pardon? V6.0 produces *warnings* if you crank the compiler up to
> a certain level; but it froze years before the C++ Standard settled
> down anyway. I believe that V7.1 is the most conforming C++ library
> on the market today. So I don't understand what you mean with this
> statement.
=========================================================================
Here's what I mean, part 1:
int main() { wchar_t justForFun; }
Compiling MSVC 7.1 as out-of-the-box, no configuration:
M:\test> cl trallala.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
trallala.cpp
trallala.cpp(1) : error C2065: 'wchar_t' : undeclared identifier
trallala.cpp(1) : error C2146: syntax error : missing ';' before identifier
'justForFun'
trallala.cpp(1) : error C2065: 'justForFun' : undeclared identifier
=========================================================================
Here's what I mean, part 2:
#include <iostream>
#include <ostream>
int main()
{
std::cout << "Here's what I mean" << std::endl;
}
Compiling MSVC 7.1 as out-of-the-box, no configuration:
M:\test> cl hullo.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
hullo.cpp
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\ostream(574)
: warning C4530: C++ exception handler used,
but unwind semantics are not enabled. Specify /EHsc
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\istream(828)
: warning C4530: C++ exception handler used,
but unwind semantics are not enabled. Specify /EHsc
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\istream(1064)
: warning C4530: C++ exception handler used
, but unwind semantics are not enabled. Specify /EHsc
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\ostream(479)
: warning C4530: C++ exception handler used,
but unwind semantics are not enabled. Specify /EHsc
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\ostream(471) : while compiling class-template mem
ber function 'std::basic_ostream<_Elem,_Traits>::_Myt
&std::basic_ostream<_Elem,_Traits>::put(_Elem)'
with
[
_Elem=wchar_t,
_Traits=std::char_traits<wchar_t>
]
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\ostream(561) : see reference to class template in
stantiation 'std::basic_ostream<_Elem,_Traits>' being compiled
with
[
_Elem=wchar_t,
_Traits=std::char_traits<wchar_t>
]
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\ostream(479)
: warning C4530: C++ exception handler used,
but unwind semantics are not enabled. Specify /EHsc
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\ostream(471) : while compiling class-template mem
ber function 'std::basic_ostream<_Elem,_Traits>::_Myt
&std::basic_ostream<_Elem,_Traits>::put(_Elem)'
with
[
_Elem=char,
_Traits=std::char_traits<char>
]
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\ostream(922) : see reference to class template in
stantiation 'std::basic_ostream<_Elem,_Traits>' being compiled
with
[
_Elem=char,
_Traits=std::char_traits<char>
]
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\istream(99) :
warning C4530: C++ exception handler used,
but unwind semantics are not enabled. Specify /EHsc
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\istream(89) : while compiling class-template memb
er function 'bool std::basic_istream<_Elem,_Traits>::_Ipfx(bool)'
with
[
_Elem=wchar_t,
_Traits=std::char_traits<wchar_t>
]
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\istream(816) : see reference to class template in
stantiation 'std::basic_istream<_Elem,_Traits>' being compiled
with
[
_Elem=wchar_t,
_Traits=std::char_traits<wchar_t>
]
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\istream(99) :
warning C4530: C++ exception handler used,
but unwind semantics are not enabled. Specify /EHsc
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\istream(89) : while compiling class-template memb
er function 'bool std::basic_istream<_Elem,_Traits>::_Ipfx(bool)'
with
[
_Elem=char,
_Traits=std::char_traits<char>
]
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\istream(1054) : see reference to class template i
nstantiation 'std::basic_istream<_Elem,_Traits>' being compiled
with
[
_Elem=char,
_Traits=std::char_traits<char>
]
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstring(1453)
: warning C4530: C++ exception handler used
, but unwind semantics are not enabled. Specify /EHsc
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\xstring(1444) : while compiling class-template me
mber function 'void
std::basic_string<_Elem,_Traits,_Ax>::_Copy(std::basic_string<_Elem,_Traits,_Ax>::size_type,std::bas
ic_string<_Elem,_Traits,_Ax>::size_type)'
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Ax=std::allocator<char>
]
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\stdexcept(39) : see reference to class template i
nstantiation 'std::basic_string<_Elem,_Traits,_Ax>' being compiled
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Ax=std::allocator<char>
]
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\ostream(713)
: warning C4530: C++ exception handler used,
but unwind semantics are not enabled. Specify /EHsc
hullo.cpp(6) : see reference to function template instantiation
'std::basic_ostream<_Elem,_Traits> &std::operato
r <<<std::char_traits<char>>(std::basic_ostream<_Elem,_Traits> &,const char
*)' being compiled
with
[
_Elem=char,
_Traits=std::char_traits<char>
]
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
/out:hullo.exe
hullo.obj
M:\test> _
Of course I'm familiar with how to configure that compiler to compile these
two small programs as standard C++, it only requires, uh, four compiler
switches, and to add support for standard C++ 'main' in general, a few more.
Hope this answered your question re what I meant,
- Alf
--
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 ]
Author: llewelly.at@xmission.dot.com (Llewelly)
Date: Sun, 20 Mar 2005 05:54:49 GMT Raw View
v.Abazarov@comAcast.net ("Victor Bazarov") writes:
> "Daryle Walker" <thedl0-usenet1@yahoo.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?
See the proposed resolution for core issue 232. It appears to allow:
T* p= 0;
T& r= *p;
---
[ 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 ]
Author: v.Abazarov@comAcast.net ("Victor Bazarov")
Date: Mon, 21 Mar 2005 01:26:30 GMT Raw View
"Llewelly" <llewelly.at@xmission.dot.com> wrote...
> v.Abazarov@comAcast.net ("Victor Bazarov") writes:
>
>> "Daryle Walker" <thedl0-usenet1@yahoo.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?
>
> See the proposed resolution for core issue 232. It appears to allow:
>
> T* p= 0;
> T& r= *p;
Nothing of the sort. It mentions 'p = 0; *p;' which will still give
undefined behaviour. Have you actually read 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.jamesd.demon.co.uk/csc/faq.html ]
Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Tue, 22 Mar 2005 20:39:02 GMT Raw View
"Alf P. Steinbach" <alfps@start.no> wrote in message
news:4239e384.935989890@news.individual.net...
>> ===================================== MODERATOR'S COMMENT:
>> Warning: severe topic drift off the starboard bow, cap'n!
Noted. Thanks for not shutting this down in the middle of a
possible disparagement.
>> > On the other hand, Microsoft's C++ compiler is out-of-the-box
>> > non-conforming
>> > wrt. to many language features (standard library header files will not
>> > compile
>> > cleanly),
>>
>> Beg pardon? V6.0 produces *warnings* if you crank the compiler up to
>> a certain level; but it froze years before the C++ Standard settled
>> down anyway. I believe that V7.1 is the most conforming C++ library
>> on the market today. So I don't understand what you mean with this
>> statement.
>
> =========================================================================
> Here's what I mean, part 1:
>
> int main() { wchar_t justForFun; }
>
> Compiling MSVC 7.1 as out-of-the-box, no configuration:
>
> M:\test> cl trallala.cpp
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for
> 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>
> trallala.cpp
> trallala.cpp(1) : error C2065: 'wchar_t' : undeclared identifier
A compiler issue, not a library header issue.
> C:\Program Files\Microsoft Visual Studio .NET
> 2003\Vc7\include\ostream(574)
> : warning C4530: C++ exception handler used,
> but unwind semantics are not enabled. Specify /EHsc
A compiler issue, not a library header issue.
> Of course I'm familiar with how to configure that compiler to compile
> these
> two small programs as standard C++, it only requires, uh, four compiler
> switches, and to add support for standard C++ 'main' in general, a few
> more.
>
> Hope this answered your question re what I meant,
Yep. It's clear now that you were identifying the library headers
as the *victim* of compiler default settings, not the *cause*
of non-conformance. Thanks.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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.jamesd.demon.co.uk/csc/faq.html ]
Author: "Stephen Howe" <sjhoweATdialDOTpipexDOTcom@eu.uu.net>
Date: Tue, 22 Mar 2005 14:39:21 CST Raw View
> When was it Standard in either C or C++?
I think he might mean there was a time wheren you could do
main()
{
}
but it was "implicit int" rather than void.
Stephen Howe
---
[ 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 ]
Author: thedl0-usenet1@yahoo.com (Daryle Walker)
Date: Wed, 23 Mar 2005 16:40:26 GMT Raw View
Marc Schoolderman <squell@alumina.nl> wrote:
> This thread from 2001, titled "Why don't we just allow void main()". It
> came up as second hit when I searched for "void main".
>
>
<http://groups-beta.google.com/group/comp.std.c++/browse_frm/thread/1376
f661c7a49c46/273b89169a5fda8d>
Said thread was started by me (who also started this thread). I knew I
did something like this before, but I couldn't find it when I tried
searching with Google Groups. Sorry if I annoyed anyone with the new
thread. At least this time I put a more precise description of the
changes.
BTW, I didn't put these proposals on this group just for discussion. I
actually do want them sent to the committee. Has that been done? If
not, is there a problem with the proposal's form or its completeness?
Should I have sent them somewhere else instead?
--
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 ]
Author: ron@sensor.com (Ron Natalie)
Date: Mon, 14 Mar 2005 19:05:09 GMT Raw View
Daryle Walker wrote:
> 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 :-)
> (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 ]
Author: "Trevor L. Jackson, III" <tlj3@comcast.net>
Date: Mon, 14 Mar 2005 13:05:19 CST Raw View
Daryle Walker wrote:
> 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 ]
Author: alfps@start.no (Alf P. Steinbach)
Date: Mon, 14 Mar 2005 19:05:03 GMT Raw View
* Daryle Walker:
> [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 <iostream> is fixed to reflect
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 ]
Author: v.Abazarov@comAcast.net ("Victor Bazarov")
Date: Mon, 14 Mar 2005 19:05:13 GMT Raw View
"Daryle Walker" <thedl0-usenet1@yahoo.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?
---
[ 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 ]
Author: francis@robinton.demon.co.uk (Francis Glassborow)
Date: Mon, 14 Mar 2005 19:05:10 GMT Raw View
In article <1gt9s1a.1ltk36qdkqctcN%thedl0-usenet1@yahoo.com>, Daryle
Walker <thedl0-usenet1@yahoo.com> writes
>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 ]
Author: jackklein@spamcop.net (Jack Klein)
Date: Mon, 14 Mar 2005 19:05:22 GMT Raw View
On Sun, 13 Mar 2005 05:54:41 GMT, thedl0-usenet1@yahoo.com (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. 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 ]
Author: francis@robinton.demon.co.uk (Francis Glassborow)
Date: Mon, 14 Mar 2005 20:16:53 GMT Raw View
In article <7eednd9CWOZfda7fRVn-qQ@comcast.com>, "Trevor L. Jackson,
III" <tlj3@comcast.net> writes
>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 ]
Author: "ThosRTanner" <ttanner2@bloomberg.net>
Date: Mon, 14 Mar 2005 18:20:06 CST Raw View
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 ]
Author: tlj3@comcast.net ("Trevor L. Jackson, III")
Date: Tue, 15 Mar 2005 00:33:43 GMT Raw View
Ron Natalie wrote:
> I'd support your idea only if we forbid falling off the end of
> the non-void main :-)
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 ]
Author: "Trevor L. Jackson, III" <tlj3@comcast.net>
Date: Mon, 14 Mar 2005 18:36:34 CST Raw View
Victor Bazarov wrote:
> "Daryle Walker" <thedl0-usenet1@yahoo.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 ]
Author: "Trevor L. Jackson, III" <tlj3@comcast.net>
Date: Mon, 14 Mar 2005 18:45:39 CST Raw View
Jack Klein wrote:
> On Sun, 13 Mar 2005 05:54:41 GMT, thedl0-usenet1@yahoo.com (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?
> 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.
>
> 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.
>
> 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
>
---
[ 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 ]
Author: house@usq.edu.au (Ron House)
Date: Tue, 15 Mar 2005 04:21:07 GMT Raw View
Trevor L. Jackson, III wrote:
> 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 house@usq.edu.au
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 ]
Author: v.Abazarov@comAcast.net ("Victor Bazarov")
Date: Tue, 15 Mar 2005 04:20:45 GMT Raw View
"Trevor L. Jackson, III" <tlj3@comcast.net> wrote...
> [...]
> 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 ]
Author: jeffrey.schwab@rcn.com (Jeff Schwab)
Date: Tue, 15 Mar 2005 04:21:41 GMT Raw View
Trevor L. Jackson, III wrote:
> But void main() is a necessity. I will not use a compiler that does not
> support the common, classic feature.
In what way is it a necessity? It's actually one character more work
than typing "int main()", which does not require an explicit "return".
---
[ 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 ]
Author: jackklein@spamcop.net (Jack Klein)
Date: Tue, 15 Mar 2005 16:20:36 GMT Raw View
On Mon, 14 Mar 2005 13:05:19 CST, "Trevor L. Jackson, III"
<tlj3@comcast.net> wrote in comp.std.c++:
[large snip]
> 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
^^^^^^^^^^^^^^^^^^^^
Chapter and verse, please. But of course, you can't.
> be no rationale for deprecating it. So it should stll be standard. In
It is no more deprecated than far pointers. You can't deprecate
something that was never part of the standard.
> practice it is and the official standard should recognize that as a fact
> (Is there a member of the Committee named Canute?)
--
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 ]
Author: v.Abazarov@comAcast.net ("Victor Bazarov")
Date: Tue, 15 Mar 2005 16:20:35 GMT Raw View
"Trevor L. Jackson, III" <tlj3@comcast.net> wrote...
> Jack Klein wrote:
>> [..]
>> 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?
There is no damage if it's not standardized either. If the things stay
as they are nothing bad is going to happen. "Possible" makes it all good,
doesn't it?
I content that there is actually serious detriment if the language is
made to cope with whatever an uneducated newbie throws at it. Effort
is spent to discuss and accept a proper form, to keep the language self-
consistent, effort is spent to adopt and implement the change everywhere.
Instead the effort has to be spent to educate the newbies and those who
write the books containing "void main".
>> 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.
Why doesn't it return a string then?
>> 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.
What problem?
> [..]
---
[ 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 ]
Author: SeeWebsiteForEmail@moderncppdesign.com ("Andrei Alexandrescu (See Website For Email)")
Date: Tue, 15 Mar 2005 16:21:02 GMT Raw View
Jeff Schwab wrote:
> Trevor L. Jackson, III wrote:
>
>> But void main() is a necessity. I will not use a compiler that does
>> not support the common, classic feature.
>
> In what way is it a necessity? It's actually one character more work
> than typing "int main()", which does not require an explicit "return".
IMHO, I think this whole discussion is silly. The committee only needs
to look at the standard and ask themselves two things, (1) what is the
best use of our time, and (2) how can we NOT increase the size of this
standard gratuitously. From that perspective, spending any time for
changing such a harmless thing like the return type of main() - a
function every single application ever implements only once! - is a tad
frivolous, IMHO. Labeling it as a necessity is kinda funny :o).
Andrei
---
[ 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 ]
Author: "dietmar_kuehl@yahoo.com" <dietmar_kuehl@yahoo.com>
Date: Tue, 15 Mar 2005 10:26:11 CST Raw View
Daryle Walker wrote:
> Declaring a program's "main" function to have a "void" return type is
a
> favorite of many, especially newbies.
Personally, I think this is a non-issue: just because people are
ignorant, it is not good reason to introduce a change. If 'main()'
should be changed, it should be changed to accommodate new system
interfaces and up to date techniques. That is, if the rules are
changed for 'main()' the following signatures should be supported:
int main()
int main(int, char*[])
int main(std::vector<std::string> const&)
int main(std::vector<std::wstring> const&)
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
---
[ 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 ]
Author: ben-public-nospam@decadentplace.org.uk (Ben Hutchings)
Date: Tue, 15 Mar 2005 16:25:34 GMT Raw View
Alf P. Steinbach wrote:
> * Daryle Walker:
>> [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).
What do you mean, theoretically? AFAIK Norwegian text can be written
entirely in ISO 8859-1 (single-byte) and certainly it can be written
in UTF-8, which is what I have been using as my default text encoding
for a while now. Only a few programs have trouble with UTF-8.
It is regrettable that certain OS vendors chose to adopt broken [*]
wide character encodings as the system default and did not at the same
time provide support for multibyte encodings covering the same
character repertoire. That does not, so far as I can see, prevent C++
implementers from providing such support.
[*] UCS-2 is broken because it cannot encode the full UCS. UTF-16
can, but it isn't really a wide character encoding.
> * 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).
Actually Windows *does* natively support quoting and escaping. See
the CommandLineToArgvW function.
The VC++ implementations of the exec* and spawn* families of functions
do not apply necessary quoting and escaping, but that's another matter
entirely.
> * 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).
This I can agree with.
> 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,
<snip>
What is the point of this? Are there really any OSs that don't have
any conventions for conversion between command lines and lists of
arguments? (There must always be at least some rule for extracting
the command name.)
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
---
[ 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 ]
Author: squell@alumina.nl (Marc Schoolderman)
Date: Tue, 15 Mar 2005 16:23:39 GMT Raw View
This thread from 2001, titled "Why don't we just allow void main()". It
came up as second hit when I searched for "void main".
http://groups-beta.google.com/group/comp.std.c++/browse_frm/thread/1376f661c7a49c46/273b89169a5fda8d
~Marc.
---
[ 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 ]
Author: tlj3@comcast.net ("Trevor L. Jackson, III")
Date: Tue, 15 Mar 2005 16:25:55 GMT Raw View
Ron House wrote:
> Trevor L. Jackson, III wrote:
>
>> 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.
No it is not. Sloppy coding is the culprit. We know this because
conformance with the int main() requirement would not be acieved by
correcting the defect, but by coplying with the letter of the law, by
chaning void to int and leaving the inadequate return status in place.
Yoo cannot legilate morality in either law or software.
> main should
> return int, and it should be an error to omit the return.
No, main() should return something meaningful. But it should only
return something meaningful if in fact it returns.
/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 ]
Author: brok@rubikon.pl ("Bronek Kozicki")
Date: Tue, 15 Mar 2005 16:24:33 GMT Raw View
Alf P. Steinbach <alfps@start.no> wrote:
> * 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).
This is good point. However, I suppose that decent support for unicode
(there is ISO standard for that, after all) in the C++ standard would
provide good foundation to solve this problem. And I do not agree that
wchar_t alone is "good enough" support for unicode.
> * 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).
I will discuss it below.
> * 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).
standard C++ library should be installed with C++ compiler, and if it is
not, then said newbie should just look for better compiler or
programming environment. If standard C++ library is available, then safe
use of command line arguments is just one line of code that's very easy
to understand and memorize:
int main(int argc, char* argv[])
{
std::vector<std::string> args(argv, argv + argc);
// ... use args instead of argc/argv
}
.. and if said newbie does not understand this code, maybe he/she
should just start learning C++ from some real handbook (like Koenig &
Moo).
> Hence I propose a standard library solution to this mess, so that we
> can write
standard library solution might be good idea for internationalization
and parsing of command line arguments, however ...
> where for e.g. Unix command_line() is synthesized, whereas for Windows
> args() is synthesized, some vague rules are in place for what
.. what names "Windows" or "Unix" do here is beyond my comprehension.
C++ is OS neutral, and making some assumptions as to behaviour of
standard library depending on particular platform is very inapropriate,
IMHO. I hope that C++ is bound to live longer than limitations of said
platforms (or specific command processors or file systems).
B.
---
[ 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 ]
Author: kuyper@wizard.net
Date: Tue, 15 Mar 2005 10:26:14 CST Raw View
ThosRTanner wrote:
> 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).
Not quite true. A return of 0 is also allowed from main(), with the
result being a successful termination status. EXIT_SUCCESS is not
required to expand into a value of 0, nor is it prohibited from doing
so. Therefore, whether there are two or three different values is
implementation-dependent.
---
[ 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 ]
Author: "Trevor L. Jackson, III" <tlj3@comcast.net>
Date: Tue, 15 Mar 2005 14:01:15 CST Raw View
Victor Bazarov wrote:
> "Trevor L. Jackson, III" <tlj3@comcast.net> wrote...
>
>>Jack Klein wrote:
>>
>>>[..]
>>>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?
>
>
> There is no damage if it's not standardized either. If the things stay
> as they are nothing bad is going to happen. "Possible" makes it all good,
> doesn't it?
>
> I content that there is actually serious detriment if the language is
> made to cope with whatever an uneducated newbie throws at it.
Many of the proponents of void main() are not newbies and do not care
what newbies want or do. The newbie issues is a red herring designed to
sidetrack the discussion by impliciyl poh-pohing the issue as noth
worthy of serious consideration.
On that topic the Committee spend the time to codify some of the
contending practices, but the elimination of void main() as a useful
expression of intent has never been adequately explained. ISTM that is
cannot be explained except as a byproduct of prejudice -- possibly
againsat newbies!
> Effort
> is spent to discuss and accept a proper form, to keep the language self-
> consistent, effort is spent to adopt and implement the change everywhere.
Yes. And "void f();" is a perfectly acceptable function prototype. That
same rule should apply to main().
>
> Instead the effort has to be spent to educate the newbies and those who
> write the books containing "void main".
Perhaps we should educate those who are ignorant of the value of void
main(). It is not an error. Nor is it "wrong". It happens to be
non-conforming, but ISTM that problem can be fixed.
>
>
>>> 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.
>
>
> Why doesn't it return a string then?
OK, strings too. Hell, return a FILE * if you want.
>
>
>>>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.
>
>
> What problem?
The problem of implementations rejecting programs containing void main().
/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 ]
Author: francis@robinton.demon.co.uk (Francis Glassborow)
Date: Tue, 15 Mar 2005 22:05:08 GMT Raw View
In article <c9KdnQ7pT8CXq6rfRVn-3A@comcast.com>, "Trevor L. Jackson,
III" <tlj3@comcast.net> writes
>The problem of implementations rejecting programs containing void main().
No the problem is the reverse, implementations accepting it. It has
never been part of C or C++ and it makes no sense for it to be so.
Programs exit normally by passing the return value of main() to exit().
It is bad enough that we allow an implicit 'return 0;' for main()
without also allowing programmers to write things that cannot be true.
Main() must return a value convertible to an int value in order to meet
the requirements of exit().
Just learn to live with it. The Standards committees have already gone
far enough/too far by allowing an implicit return. There is absolutely
no justification for endorsing an entirely bogus 'void' return type for
main()
>
--
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 ]
Author: "ThosRTanner" <ttanner2@bloomberg.net>
Date: Tue, 15 Mar 2005 21:46:35 CST Raw View
Jack Klein wrote:
[snip]
> ... 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.
There is a good argument for a bool or an enumeration being returned,
in that if an int is anything other than EXIT_FAILURE or EXIT_SUCCESS,
what is returned to the caller is implementation specific. And, yes, I
have seen cases where main has returned a number that on one system
indicates an error to the caller, and on another returns success.
---
[ 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 ]
Author: wade@stoner.com
Date: Tue, 15 Mar 2005 21:46:47 CST Raw View
Francis Glassborow wrote:
> In article <7eednd9CWOZfda7fRVn-qQ@comcast.com>, "Trevor L. Jackson,
> III" <tlj3@comcast.net> writes
> >But void main() is a necessity. ... It was once standard ...
>
> 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.
There are standards and Standards. I'd certainly argue that contiguous
std::vector was the standard, even before it was Standard. Once upon a
time there was no keyword void, but "implicit-int" functions could exit
without an explicit return value.
I don't have my K&R here, but I believe it has examples similar to
http://www.lysator.liu.se/c/bwk-tutor.html which shows functions like
count(){ ... return; }
main(){ printf("hello world\n"); }
If you are going to change the language by adding "void" and getting
rid of implicit-int, then my automatic translator would probably change
those functions to
void count(){ ... return; }
void main(){ printf("hello world\n"); }
As a personal preference, I believe that
int main(){ return; }
is uglier than
void main(){ return; }
but I wouldn't mind if both of were non-Standard.
---
[ 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 ]