The worst 'hello world' example ever written...

9 views
Skip to first unread message

C

unread,
Sep 14, 2003, 8:42:24 AM9/14/03
to
The_Sage <thee...@azrmci.net> wrote in message news:<eq15mv4p3rjavv0tq...@4ax.com>...
> >Reply to article by: black...@asean-mail.com (C)
> >Date written: 12 Sep 2003 04:59:48 -0700
> >MsgID:<33d97ee5.03091...@posting.google.com>

[Cross posted to comp.lang.c++ as an example of the worst
'hello world' example ever written in C++, please point out
any errors I have missed. (The original poster (The_Sage)
proposes this example is 100% correct, I submit it to the
experts for critique.)]

> >>you embarass yourself everytime you open your mouth.
>
> >> #include <iostream.h>
> >> void main() { cout << "Hello, World!" }
>
> >I have been letting this slip as I post enough errors
> >in my code; though I will do so no longer as this is the
> >third time you have repeated it without corrections. You
> >"embarass yourself everytime you" post this code. Here
> >are comments and corrections...
>
> >You wrote
> >#include <iostream.h> // should be no ".h"
>
> Wrong.

Not wrong, your specification is bad practice, and not the C++
idiom for the inclusion of C++ headers.

> >void // Standard says should be "int"
>
> No it doesn't, since cout doesn't return anything.

The return from 'cout' is irrelevant; this is C++ not
functional programming.

gemini(300)$ cat sag.cc
#include <iostream.h>
void main(){ cout << "Hello, World!" }
gemini(301)$ g++ -Wall sag.cc
sag.cc: At global scope:
sag.cc:2: `main' must return `int'
sag.cc:2: return type for `main' changed to `int'
sag.cc: In function `int main(...)':
sag.cc:2: parse error before `}' token
gemini(302)$ g++ --version
3.0

> >main() { // ok (can omit int n, char**v )
>
> Duh.
>
> >cout << "Hello, World!" // buffer is not flushed
>
> No need to.

Yes there is, some systems will not print anything otherwise.
Do you really want the portability which is the only real
advantage of C++ in this application?

> > // no ";"
>
> The "}" takes care of that last ";".

No it does not; this is C++ not Pascal. See the above gcc
error messages.

> > // no return
>
> That's what the following is...
>
> >}

Are you (The_Sage) completely unable to admit even the
simplest error? We all make mistakes, but when 99% of the
people on the group are confronted with one they would just
say 'whoopsy daisy, this is what I ment...', but not you.
You could have just replied 'oops, typo' and would most
probably have been duely forgiven, but instead you constantly
paint yourself into a corner as more and more evidence
proving you are wrong comes to light, loosing all credability
in the process.

I have posted this across to 'comp.lang.c++' as the people
there know C++ much better than I. I am sure they will be
able to inform you of exactly which parts of the standard
you have broken.

C
2003/9/14

PS: I am unsure whether the C++ standard specifies the auto
generation of the 'return 0;' sequence on the main() procedure
and would appreciate clarification on this matter.

Buster Copley

unread,
Sep 14, 2003, 10:41:01 AM9/14/03
to
C wrote:
> The_Sage <thee...@azrmci.net> wrote

> [Cross posted to comp.lang.c++ as an example of the worst
> 'hello world' example ever written in C++, please point out
> any errors I have missed. (The original poster (The_Sage)
> proposes this example is 100% correct, I submit it to the
> experts for critique.)]

>>>> #include <iostream.h>


>>>> void main() { cout << "Hello, World!" }

>>>I have been letting this slip as I post enough errors
>>>in my code; though I will do so no longer as this is the
>>>third time you have repeated it without corrections. You
>>>"embarass yourself everytime you" post this code. Here
>>>are comments and corrections...

>>>You wrote
>>>#include <iostream.h> // should be no ".h"
>>
>>Wrong.
>
> Not wrong, your specification is bad practice, and not the C++
> idiom for the inclusion of C++ headers.

http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.4

>>>void // Standard says should be "int"
>>
>>No it doesn't, since cout doesn't return anything.
>
> The return from 'cout' is irrelevant; this is C++ not
> functional programming.

http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.3

cout is not a function; the name of the function which is called here is
'operator <<', and its return type is 'ostream &' (or more precisely,
'std::basic_ostream <char, std::char_traits <char> > &'). This is indeed
irrelevant to the return type of 'main', which is always int.

> gemini(300)$ cat sag.cc
> #include <iostream.h>
> void main(){ cout << "Hello, World!" }
> gemini(301)$ g++ -Wall sag.cc
> sag.cc: At global scope:
> sag.cc:2: `main' must return `int'
> sag.cc:2: return type for `main' changed to `int'
> sag.cc: In function `int main(...)':
> sag.cc:2: parse error before `}' token
> gemini(302)$ g++ --version
> 3.0
>
>>>main() { // ok (can omit int n, char**v )
>>
>>Duh.

Not OK. Main always returns int and there is no 'implicit int' in C or
in C++.

>>>cout << "Hello, World!" // buffer is not flushed
>>
>>No need to.
>
> Yes there is, some systems will not print anything otherwise.
> Do you really want the portability which is the only real
> advantage of C++ in this application?

The buffer will be flushed when the cout object is destroyed. A newline
might be nice though.

>>> // no ";"
>>
>>The "}" takes care of that last ";".
>
> No it does not; this is C++ not Pascal. See the above gcc
> error messages.

That's right, C++ is not Perl and you do need the semicolon.

>>> // no return
>>
>>That's what the following is...
>>
>>>}

Not really; that's just a closing brace. The return is implicit. main
implicitly returns 0 (EXIT_SUCCESS) when the closing brace is reached.

[snip]

> PS: I am unsure whether the C++ standard specifies the auto
> generation of the 'return 0;' sequence on the main() procedure
> and would appreciate clarification on this matter.

Auto generation is a funny way of looking at it, but yes, the effect is
as if there were a 'return 0;' before the closing brace.

Here's one way of doing it correctly:

#include <iostream>
int main () { std::cout << "Hello, world!\n"; }

Questions? Comments? Suggestions?
Regards,
Buster.

White Wolf

unread,
Sep 14, 2003, 11:39:10 AM9/14/03
to
C wrote:
> The_Sage <thee...@azrmci.net> wrote in message
> news:<eq15mv4p3rjavv0tq...@4ax.com>...
>>> Reply to article by: black...@asean-mail.com (C)
>>> Date written: 12 Sep 2003 04:59:48 -0700
>>> MsgID:<33d97ee5.03091...@posting.google.com>
>
> [Cross posted to comp.lang.c++ as an example of the worst
> 'hello world' example ever written in C++, please point out
> any errors I have missed. (The original poster (The_Sage)
> proposes this example is 100% correct, I submit it to the
> experts for critique.)]
[SNIP]

The guy is either a troll or a simpleton. Just ignore him.

--
WW aka Attila


Kevin Goodsell

unread,
Sep 14, 2003, 4:01:54 PM9/14/03
to
C wrote:

>
>
> [Cross posted to comp.lang.c++ as an example of the worst
> 'hello world' example ever written in C++, please point out
> any errors I have missed. (The original poster (The_Sage)
> proposes this example is 100% correct, I submit it to the
> experts for critique.)]

We already had a thread making fun of this code earlier this week...

>
>
>>>>you embarass yourself everytime you open your mouth.
>>
>>
>>
>>>> #include <iostream.h>
>>>> void main() { cout << "Hello, World!" }

The main problems are:

* Non-standard (actually old, pre-standard) header. <iostream.h> no
longer exists in C++. The replacement is <iostream>

* Incorrect return type for main. The standard explicitly states that
main must return int. In fact, every document that has ever been
accepted as a standard for either C or C++ has required an 'int' return
type for main. Some allowed it to be implicit if the return type was
omitted. This is no longer allowed in either language.

* The output may never be seen. This is not a problem with flushing
(cout will be flushed when it is destroyed on program termination). It
is a problem with not properly terminating the line. A C++ program
should end it's output with a newline.

* Once the correct header is used, cout is placed in the std namespace,
therefore it's full name is std::cout. It can either be referred to
using this fully qualified name or the name can be brought into scope
using a 'using' statement.

* Missing semi-colon after the one and only statement in main().


(referring to <iostream.h>

>
> Not wrong, your specification is bad practice, and not the C++
> idiom for the inclusion of C++ headers.

<iostream.h> does not exist in standard C++. It's as simple as that.

>
>
>>>void // Standard says should be "int"
>>
>>No it doesn't, since cout doesn't return anything.

Clearly a fundamental misunderstanding of how the language works.

>>>cout << "Hello, World!" // buffer is not flushed
>>
>>No need to.
>
>
> Yes there is, some systems will not print anything otherwise.

The buffer is flushed, but the output still may not be seen without a
newline.

>>The "}" takes care of that last ";".

Another fundamental misunderstanding about the language. Semi-colons
terminate C++ statements, they don't separate them. A semicolon after
the 'cout' statement is necessary.

The corrected code looks like this:

#include <iostream> // no .h
int main() // returns int
{ std::cout << "Hello, World!\n"; } // std::, newline, semicolon.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Josh Sebastian

unread,
Sep 14, 2003, 4:42:32 PM9/14/03
to
On Sun, 14 Sep 2003 20:01:54 +0000, Kevin Goodsell wrote:

> In fact, every document that has ever been
> accepted as a standard for either C or C++ has required an 'int' return
> type for main.

<OT>
This is not true. In C, an implementation is required to accept a program
which defines main with an int return type, but it is
implementation-defined whether (and which) other return types are
acceptable.
</OT>

> * The output may never be seen. This is not a problem with flushing
> (cout will be flushed when it is destroyed on program termination). It
> is a problem with not properly terminating the line. A C++ program
> should end it's output with a newline.

It's implementation-defined. From C99 draft n869, 7.19.2:

A text stream is an ordered sequence of characters composed into lines,
each line consisting of zero or more characters plus a terminating
new-line character. Whether the last line requires a terminating
new-line character is implementation-defined.

Josh

Kevin Goodsell

unread,
Sep 14, 2003, 5:06:58 PM9/14/03
to
Josh Sebastian wrote:

>
> <OT>
> This is not true. In C, an implementation is required to accept a program
> which defines main with an int return type, but it is
> implementation-defined whether (and which) other return types are
> acceptable.
> </OT>

Yeah, that's true. Kind of a technicality though... if you expect your
code to work on a standard compiler, you still have to use 'int' as
main's return type.

>
>>* The output may never be seen. This is not a problem with flushing
>>(cout will be flushed when it is destroyed on program termination). It
>>is a problem with not properly terminating the line. A C++ program
>>should end it's output with a newline.
>
>
> It's implementation-defined. From C99 draft n869, 7.19.2:
>
> A text stream is an ordered sequence of characters composed into lines,
> each line consisting of zero or more characters plus a terminating
> new-line character. Whether the last line requires a terminating
> new-line character is implementation-defined.
>
> Josh

2 things: 1, I'm not sure why you are referencing C99 for a C++
discussion - it may or may not be applicable. 2, that wording might be
intended as a warning not to count on the last line of your *input*
being properly terminated. I wonder if there's a more explicit statement
about terminating the last line of the standard output - I think I've
heard that there is.

I'm sure it's either undefined or implementation defined, though. In any
case, it's best to terminate output with a newline.

Josh Sebastian

unread,
Sep 14, 2003, 5:41:45 PM9/14/03
to
On Sun, 14 Sep 2003 21:06:58 +0000, Kevin Goodsell wrote:

> Josh Sebastian wrote:

>>>* The output may never be seen. This is not a problem with flushing
>>>(cout will be flushed when it is destroyed on program termination). It
>>>is a problem with not properly terminating the line. A C++ program
>>>should end it's output with a newline.
>>
>>
>> It's implementation-defined. From C99 draft n869, 7.19.2:
>>
>> A text stream is an ordered sequence of characters composed into lines,
>> each line consisting of zero or more characters plus a terminating
>> new-line character. Whether the last line requires a terminating
>> new-line character is implementation-defined.
>

> 2 things: 1, I'm not sure why you are referencing C99 for a C++
> discussion - it may or may not be applicable.

Section 7 of C90, with a few exceptions, is normative in C++98. I don't
have a copy of C90, but I assume (I know -- dangerous) that the wording is
similar.

> 2, that wording might be
> intended as a warning not to count on the last line of your *input*
> being properly terminated. I wonder if there's a more explicit statement
> about terminating the last line of the standard output - I think I've
> heard that there is.

I couldn't find one, but that doesn't mean it isn't there.

> I'm sure it's either undefined or implementation defined, though. In any
> case, it's best to terminate output with a newline.

True.

Josh

The_Sage

unread,
Sep 14, 2003, 8:45:57 PM9/14/03
to
>Reply to article by: black...@asean-mail.com (C)
>Date written: 14 Sep 2003 05:42:24 -0700
>MsgID:<33d97ee5.03091...@posting.google.com>

>[Cross posted to comp.lang.c++ as an example of the worst
>'hello world' example ever written in C++, please point out
>any errors I have missed. (The original poster (The_Sage)
>proposes this example is 100% correct, I submit it to the
>experts for critique.)]

Yes, and they whipped your ass too.

The Sage

=============================================================
My Home Page : http://members.cox.net/the.sage

"The men that American people admire most extravagantly are
most daring liars; the men they detest the most violently are
those who try to tell them the truth" -- H. L. Mencken
=============================================================

The_Sage

unread,
Sep 14, 2003, 9:09:49 PM9/14/03
to
>Reply to article by: Kevin Goodsell <usenet1.spa...@neverbox.com>
>Date written: Sun, 14 Sep 2003 20:01:54 GMT
>MsgID:<SO39b.3450$BS5....@newsread4.news.pas.earthlink.net>

>>[Cross posted to comp.lang.c++ as an example of the worst
>>'hello world' example ever written in C++, please point out
>>any errors I have missed. (The original poster (The_Sage)
>>proposes this example is 100% correct, I submit it to the
>>experts for critique.)]

>We already had a thread making fun of this code earlier this week...

As we will see, the laugh is on you...

>>>>>you embarass yourself everytime you open your mouth.

>>>>> #include <iostream.h>
>>>>> void main() { cout << "Hello, World!" }

>The main problems are:

>* Non-standard (actually old, pre-standard) header. <iostream.h> no
>longer exists in C++. The replacement is <iostream>

It isn't non-standard, is just isn't specified in the standard that way. It is
on your hard drive as "iostream.h" and you can use it both ways, just one way is
standard and the other is not.

>* Incorrect return type for main. The standard explicitly states that
>main must return int. In fact, every document that has ever been
>accepted as a standard for either C or C++ has required an 'int' return
>type for main. Some allowed it to be implicit if the return type was
>omitted. This is no longer allowed in either language.

The C standard (ISO/IEC 9899:1999) does not require main() to return anything
although the C++ standard does. But ISO C++ Standard (ISO/IEC 14882:1998)
specifically requires main to return int although you *can* use void main() in
IBM, WATCOM, or MS C++ (as well as other) ISO compliant compilers.
http://homepages.tesco.net/~J.deBoynePollard/FGA/legality-of-void-main.html

>* The output may never be seen. This is not a problem with flushing
>(cout will be flushed when it is destroyed on program termination). It
>is a problem with not properly terminating the line. A C++ program
>should end it's output with a newline.

Obviously you are an armchair programmer since you are merely guessing. All that
will happen is this...

C:\>Hello
Hello World
C:\

Instead of...

C:\>Hello
Hello World

C:\

No guessing needed! Funny how the real world works like that, eh?

>* Once the correct header is used, cout is placed in the std namespace,
>therefore it's full name is std::cout. It can either be referred to
>using this fully qualified name or the name can be brought into scope
>using a 'using' statement.

Or you can set it in some compilers to default to namespaces by default...which
most do.

>* Missing semi-colon after the one and only statement in main().

That's because it isn't required in all cases. The bracket takes care of that
one special case where it isn't required.

>(referring to <iostream.h>

>>Not wrong, your specification is bad practice, and not the C++
>>idiom for the inclusion of C++ headers.

><iostream.h> does not exist in standard C++. It's as simple as that.

Yes it does. Just do a file search for it on your computer (presuming you have a
ISO compliant C++ compiler installed on it).

>>>>void // Standard says should be "int"

>>>No it doesn't, since cout doesn't return anything.

>Clearly a fundamental misunderstanding of how the language works.

Oh yes, "clearly". Not even close. Haha! You are so full of shit.

Kevin Goodsell

unread,
Sep 14, 2003, 9:41:41 PM9/14/03
to
The_Sage wrote:
>>Reply to article by: Kevin Goodsell <usenet1.spa...@neverbox.com>
>
>>* Non-standard (actually old, pre-standard) header. <iostream.h> no
>>longer exists in C++. The replacement is <iostream>
>
>
> It isn't non-standard, is just isn't specified in the standard that way. It is
> on your hard drive as "iostream.h" and you can use it both ways, just one way is
> standard and the other is not.

My hard drive does not define what is and is not standard. Neither does
yours. <iostream.h> is not standard. Even when it is supplied with a
compiler it is probably not the same as <iostream>. Things have changed
since ARM C++.

> The C standard (ISO/IEC 9899:1999) does not require main() to return anything

A technicality. You still can't use 'void' if you expect your code to
compile on a standard compliant compiler.

> although the C++ standard does.

Yes, it does. And you used void anyway. Therefore you were wrong.

> But ISO C++ Standard (ISO/IEC 14882:1998)
> specifically requires main to return int although you *can* use void main() in
> IBM, WATCOM, or MS C++ (as well as other) ISO compliant compilers.

Are you sure? The lack of a compiler error does not make it correct. The
standard does not require a diagnostic for an incorrect return type for
main.

> http://homepages.tesco.net/~J.deBoynePollard/FGA/legality-of-void-main.html

Wow, you can use a search engine.

>
>
>>* The output may never be seen. This is not a problem with flushing
>>(cout will be flushed when it is destroyed on program termination). It
>>is a problem with not properly terminating the line. A C++ program
>>should end it's output with a newline.
>
>
> Obviously you are an armchair programmer since you are merely guessing. All that
> will happen is this...
>
> C:\>Hello
> Hello World
> C:\
>
> Instead of...
>
> C:\>Hello
> Hello World
>
> C:\
>
> No guessing needed! Funny how the real world works like that, eh?

Yeah, funny. There are any number of compilers/systems out there that
won't display this output. We've seen several posts here where somebody
said "My hello world program isn't working" and the problem was actually
that they failed to properly terminate the output. It seems you are the
one that's guessing, based on very limited experience.

>
>
>>* Once the correct header is used, cout is placed in the std namespace,
>>therefore it's full name is std::cout. It can either be referred to
>>using this fully qualified name or the name can be brought into scope
>>using a 'using' statement.
>
>
> Or you can set it in some compilers to default to namespaces by default...which
> most do.

That sentence doesn't even make sense.

A standard-compliant compiler must issue a diagnostic for code that
fails to properly qualify names, or bring them into scope with a 'using'
statement.

>
>
>>* Missing semi-colon after the one and only statement in main().
>
>
> That's because it isn't required in all cases.

It is in this case.

> The bracket takes care of that
> one special case where it isn't required.

I don't know what this means, but the bracket has nothing to do with
your missing semicolon. Though you may be able to find (broken)
compilers that allow 'void main' and no namespaces, I doubt you can find
any compiler that will accept the missing semicolon.

>
>><iostream.h> does not exist in standard C++. It's as simple as that.
>
>
> Yes it does. Just do a file search for it on your computer (presuming you have a
> ISO compliant C++ compiler installed on it).

Again, what's on my computer has nothing to do with what is standard.
<iostream.h> is not standard.

>
> Oh yes, "clearly". Not even close. Haha! You are so full of shit.

Everyone here knows which of us is full of shit.

Greg Schmidt

unread,
Sep 14, 2003, 9:45:14 PM9/14/03
to
On Sun, 14 Sep 2003 18:09:49 -0700, The_Sage <thee...@azrmci.net>
wrote:

>>Reply to article by: Kevin Goodsell <usenet1.spa...@neverbox.com>
>>Date written: Sun, 14 Sep 2003 20:01:54 GMT
>>MsgID:<SO39b.3450$BS5....@newsread4.news.pas.earthlink.net>
>

>>* Non-standard (actually old, pre-standard) header. <iostream.h> no
>>longer exists in C++. The replacement is <iostream>
>
>It isn't non-standard, is just isn't specified in the standard that way. It is
>on your hard drive as "iostream.h" and you can use it both ways, just one way is
>standard and the other is not.

Okay, so one way is not standard, but that doesn't make it non-standard?
What kind of logic is that?

The standard does not preclude a compiler manufacturer from including
extra non-standard header files with their distribution. An example you
might know would be windows.h Such inclusion does not make them
standard.

>you *can* use void main() in
>IBM, WATCOM, or MS C++ (as well as other) ISO compliant compilers.
>http://homepages.tesco.net/~J.deBoynePollard/FGA/legality-of-void-main.html

This is what's known as a "non-standard extension". Just because IBM
and MS support it doesn't make it standard.

>>* The output may never be seen. This is not a problem with flushing
>>(cout will be flushed when it is destroyed on program termination). It
>>is a problem with not properly terminating the line. A C++ program
>>should end it's output with a newline.
>
>Obviously you are an armchair programmer since you are merely guessing. All that
>will happen is this...
>
> C:\>Hello
> Hello World
> C:\
>
>Instead of...
>
> C:\>Hello
> Hello World
>
> C:\

What's this C:\ thing? My prompt looks like this:
(gregs) $
Have you ever tried any UNIX compilers, or are you merely guessing that
they will exhibit similar properties to Windows compilers? Here's what
it might look like if I ran that same app here:

(gregs) $ hello
Hello World(gregs) $

or maybe like this:

(gregs) $ hello
(gregs) $

Here's something else it might look like:
(gregs) $ hello
Segmentation fault, core dumped.
(gregs) $

>No guessing needed! Funny how the real world works like that, eh?

Funny how the portion of the real world with which you are familiar is
like that. Funny how you believe that the entire real world is the same
as your experiences. Funny how long it might take you to track down
this bug when you port to a compiler which you are not familiar with,
and which implements "implementation defined" behaviour differently from
what you expect. Well, funny for us; not so funny for the guy that pays
you for the time it takes you to debug your port. The guess involved is
the one where you guess that other compilers (including future versions
of compiler X) work just like compiler X.

>>* Once the correct header is used, cout is placed in the std namespace,
>>therefore it's full name is std::cout. It can either be referred to
>>using this fully qualified name or the name can be brought into scope
>>using a 'using' statement.
>
>Or you can set it in some compilers to default to namespaces by default...which
>most do.

What does "default to namespaces by default" mean?

>>* Missing semi-colon after the one and only statement in main().
>
>That's because it isn't required in all cases. The bracket takes care of that
>one special case where it isn't required.

As others have said here, it is in fact required by the standard. If
your compiler doesn't require it, then that's another non-standard
extension that you would be well advised not to rely on.

>><iostream.h> does not exist in standard C++. It's as simple as that.
>
>Yes it does. Just do a file search for it on your computer (presuming you have a
>ISO compliant C++ compiler installed on it).

Hey, I found a file on my computer called TheSageIsABigIdiot.wiffle.blat
I guess it must be a part of standard C++, since I have an ISO compliant
C++ compiler installed. What's that, you say the file wasn't put there
by installing the compiler? Okay then, how about this other file called
g++ which was installed with the compiler, is that part of standard C++?

>>>>>void // Standard says should be "int"
>
>>>>No it doesn't, since cout doesn't return anything.
>
>>Clearly a fundamental misunderstanding of how the language works.
>
>Oh yes, "clearly". Not even close. Haha! You are so full of shit.

cout isn't a function, it's an object. Objects don't return anything,
only functions do. And, as pointed out elsewhere, the function in
question ("<<") does return something. And the original comment was
with respect to the return value of main, which has absolutely nothing
to do with the return value of "<<". Seems pretty clear to me that
whoever wrote the "No it doesn't" line has demonstrated a fundamental
misunderstanding of at least 3 facets of the language, all in a single
sentence. If you don't see this, then you are also suffering from the
same misunderstanding.

>"The men that American people admire most extravagantly are
>most daring liars; the men they detest the most violently are
>those who try to tell them the truth" -- H. L. Mencken

A-ha! I understand now! Sage is trying to become someone that American
people admire most extravagantly! He is afraid that if he posts factual
information or agrees with obvious truths he will become most violently
detested. Let me assure you, Sage, Mr. Mencken was not referring to
technical newsgroups when he made that statement.

--
Greg Schmidt (gr...@trawna.com)
Trawna Publications (http://www.trawna.com/)

Jonathan Mcdougall

unread,
Sep 14, 2003, 11:32:22 PM9/14/03
to
>>>>>>you embarass yourself everytime you open your mouth.
>
>>>>>> #include <iostream.h>
>>>>>> void main() { cout << "Hello, World!" }
>
>>The main problems are:
>
>>* Non-standard (actually old, pre-standard) header. <iostream.h> no
>>longer exists in C++. The replacement is <iostream>
>
>It isn't non-standard, is just isn't specified in the standard that way. It is
>on your hard drive as "iostream.h" and you can use it both ways, just one way is
>standard and the other is not.

We discuss standard C++ here. If you have some problems with a
specific implementation, please take the discussion to its dedicated
newgroup.

>>* Incorrect return type for main. The standard explicitly states that
>>main must return int. In fact, every document that has ever been
>>accepted as a standard for either C or C++ has required an 'int' return
>>type for main. Some allowed it to be implicit if the return type was
>>omitted. This is no longer allowed in either language.
>
>The C standard (ISO/IEC 9899:1999) does not require main() to return anything
>although the C++ standard does.

In both standards, main() is required to return int. Please, try to
be informed before posting such false statements.

>But ISO C++ Standard (ISO/IEC 14882:1998)
>specifically requires main to return int although you *can* use void main() in
>IBM, WATCOM, or MS C++ (as well as other) ISO compliant compilers.
>http://homepages.tesco.net/~J.deBoynePollard/FGA/legality-of-void-main.html

This is not a standard behavior and this newsgroup only discusses
standard C++. If you have some problems with a specific
implementation, please take the discussion to its dedicated newgroup.

>>* The output may never be seen. This is not a problem with flushing
>>(cout will be flushed when it is destroyed on program termination). It
>>is a problem with not properly terminating the line. A C++ program
>>should end it's output with a newline.
>
>Obviously you are an armchair programmer since you are merely guessing. All that
>will happen is this...
>
> C:\>Hello
> Hello World
> C:\
>
>Instead of...
>
> C:\>Hello
> Hello World
>
> C:\
>
>No guessing needed! Funny how the real world works like that, eh?

We do not discuss the real world, we discuss standard C++. On one of
the implementations I work on, nothing is displayed since there is no
screen.

Standard C++ does not force implementations to flush the buffer when
std::cout is destroyed. If you have some problems with a specific
implementation, please take the discussion to its dedicated newgroup.

>>* Once the correct header is used, cout is placed in the std namespace,
>>therefore it's full name is std::cout. It can either be referred to
>>using this fully qualified name or the name can be brought into scope
>>using a 'using' statement.
>
>Or you can set it in some compilers to default to namespaces by default...which
>most do.

Implementation-defined behaviors are not discussed here. If you have
some problems with a specific implementation, please take the
discussion to its dedicated newgroup.

>>* Missing semi-colon after the one and only statement in main().
>
>That's because it isn't required in all cases. The bracket takes care of that
>one special case where it isn't required.

Wrong. Please try to get informed before posting such false
statements.

>>(referring to <iostream.h>
>
>>>Not wrong, your specification is bad practice, and not the C++
>>>idiom for the inclusion of C++ headers.
>
>><iostream.h> does not exist in standard C++. It's as simple as that.
>
>Yes it does. Just do a file search for it on your computer (presuming you have a
>ISO compliant C++ compiler installed on it).

Minesweeper also exists on my computer, yet it is not standard C++.
Just because a header is shipped with a compiler does not mean it is
standard.

>>>>>void // Standard says should be "int"
>
>>>>No it doesn't, since cout doesn't return anything.
>
>>Clearly a fundamental misunderstanding of how the language works.
>
>Oh yes, "clearly". Not even close. Haha! You are so full of shit.

Please try to respect other posters, as we try to respect you.


What point are you trying to make here? You definitly know you are
wrong. Either you are a troll or you have some serious problems with
your keyboard.


Jonathan

C

unread,
Sep 15, 2003, 6:48:47 PM9/15/03
to
Buster Copley <bus...@none.com> wrote in message news:<bk1umr$iea$1...@news7.svr.pol.co.uk>...

> C wrote:
> > The_Sage <thee...@azrmci.net> wrote

[snip]

> >>>main() { // ok (can omit int n, char**v )
> >>
> >>Duh.
>
> Not OK. Main always returns int and there is no 'implicit int' in C or
> in C++.

My original post (on alt.lang.asm) had the quoted example
on contigious lines, it got a little split up in the reply.
You are, never the less, entirely correct in your assertion.

[snip]

> >>> // no return
> >>
> >>That's what the following is...
> >>
> >>>}
>
> Not really; that's just a closing brace. The return is implicit.
> main implicitly returns 0 (EXIT_SUCCESS) when the closing brace
> is reached.

I must admit to being rather surprised that a return with a value
can be implied, is this just for the main() procedure or does it
apply to all functions and if the latter, surely it would be good
practice to write the return anyway?

[snip]

> Here's one way of doing it correctly:
>
> #include <iostream>
> int main () { std::cout << "Hello, world!\n"; }

Ah! My counter example was almost correct (I do not think it made
it to comp.lang.c++ : see alt.lang.asm if you are interested), not
bad for someone who has neither a C++ compiler (at the time of
writing) or any knowledge of the C++ standard. :-)

Anyway I will probably take the time to learn C++ properly (no
need to ask the opinions of all at comp.lang.c++ -- I am sure you
all think that a good idea), to that end your FAQ is comming in
very handy. Thanks.

C
2003/9/15

C

unread,
Sep 15, 2003, 7:10:01 PM9/15/03
to
"White Wolf" <wo...@freemail.hu> wrote in message news:<bk2234$442$1...@phys-news1.kolumbus.fi>...

[snip]

> The guy is either a troll or a simpleton. Just ignore him.

I wish that where possible, the arguments he (TSag) posts to
alt.lang.asm are totally against assembly programming and
founded on misconceptions which have not been true for years.
Sadly his arguments have just enough of a veneer of accuracy
that they cannot be simply ignored and must be confronted
else non experts in the field may be mislead -- the results
of proving him wrong you have seen in this thread.

So troll, yes, probably, but turning a blind eye is not an
option if new programmers are to be pursuaded that learning
the assembly paradigm is a good idea. Thanks for the reply
anyway.

C
2003/9/15

PS: Hopefully he will either go and pester another group, or
preferably, quite down, learn the subject properly, and become
a helpful member of the group.

PPS: Sorry for swinging rather offtopic for comp.lang.c++,
an explaination seemed in order -- pop over to alt.lang.asm
to see what has been happening for the last few months for a
better picture. [Please direct any follow ups to this post
there.]

Kevin Goodsell

unread,
Sep 15, 2003, 9:10:48 PM9/15/03
to
C wrote:
>
> I must admit to being rather surprised that a return with a value
> can be implied, is this just for the main() procedure or does it
> apply to all functions and if the latter, surely it would be good
> practice to write the return anyway?

It only applies to main. A similar rule was adopted into the C language
with the C99 major update.

Randall Hyde

unread,
Sep 15, 2003, 10:00:28 PM9/15/03
to

"Kevin Goodsell" <usenet1.spa...@neverbox.com> wrote in message
news:pN89b.3798$BS5....@newsread4.news.pas.earthlink.net...

> The_Sage wrote:
>
> > http://homepages.tesco.net/~J.deBoynePollard/FGA/legality-of-void-main.html
>
> Wow, you can use a search engine.

:-)
Based on my experience, that's about *all* he can do.
You should see his "Software Engineering" arguments.
Cheers,
Randy Hyde


Randall Hyde

unread,
Sep 15, 2003, 10:03:43 PM9/15/03
to

"The_Sage" <thee...@azrmci.net> wrote in message news:jt2amvoh60ikim7op...@4ax.com...

> >Reply to article by: black...@asean-mail.com (C)
> >Date written: 14 Sep 2003 05:42:24 -0700
> >MsgID:<33d97ee5.03091...@posting.google.com>
>
> >[Cross posted to comp.lang.c++ as an example of the worst
> >'hello world' example ever written in C++, please point out
> >any errors I have missed. (The original poster (The_Sage)
> >proposes this example is 100% correct, I submit it to the
> >experts for critique.)]
>
> Yes, and they whipped your ass too.


I think that this is reasonable proof that TS ignores reality.
There is a special name for people who ignore reality: insane.
I've avoided tagging TS with this label as I don't enjoy calling
people names like this, but now he's gone completely over the
edge.

As it is a complete waste of time to engage in conversation
with an insane person, it's time to expand my killfile.
Cheers,
Randy Hyde


The_Sage

unread,
Sep 15, 2003, 10:11:36 PM9/15/03
to
>Reply to article by: Kevin Goodsell <usenet1.spa...@neverbox.com>
>Date written: Mon, 15 Sep 2003 01:41:41 GMT
>MsgID:<pN89b.3798$BS5....@newsread4.news.pas.earthlink.net>

>>>Non-standard (actually old, pre-standard) header. <iostream.h> no
>>>longer exists in C++. The replacement is <iostream>

>>It isn't non-standard, is just isn't specified in the standard that way. It is
>>on your hard drive as "iostream.h" and you can use it both ways, just one way is
>>standard and the other is not.

>My hard drive does not define what is and is not standard. Neither does
>yours. <iostream.h> is not standard. Even when it is supplied with a
>compiler it is probably not the same as <iostream>. Things have changed
>since ARM C++.

Whether it is a standard or not, it is acceptable. IBM, MS, and Borland all
agree with my interpretation of the standard and not yours.

>>The C standard (ISO/IEC 9899:1999) does not require main() to return anything

>A technicality. You still can't use 'void' if you expect your code to
>compile on a standard compliant compiler.

Then explain why it compiles on three standard compilers, ie -- IBM, MS, and
Borland?

>>although the C++ standard does.

>Yes, it does. And you used void anyway. Therefore you were wrong.

All the standard says is that main() must return an integer, not that you must
use whatever it returns. If you don't care what main() returns, you can use void
to "discard" it. Again, IBM, MS, and Borland agree with my interpretation and
not yours.

>>But ISO C++ Standard (ISO/IEC 14882:1998)
>>specifically requires main to return int although you *can* use void main() in
>>IBM, WATCOM, or MS C++ (as well as other) ISO compliant compilers.

>Are you sure? The lack of a compiler error does not make it correct.

Nor does it make it incorrect. Try another logical fallacy.

>The
>standard does not require a diagnostic for an incorrect return type for
>main.

Hence the reason it is perfectly acceptable to ignore what main() returns by
using void.

>>http://homepages.tesco.net/~J.deBoynePollard/FGA/legality-of-void-main.html

>Wow, you can use a search engine.

Wow, and you can't refute a simple search engine article.

>>>* The output may never be seen. This is not a problem with flushing
>>>(cout will be flushed when it is destroyed on program termination). It
>>>is a problem with not properly terminating the line. A C++ program
>>>should end it's output with a newline.

>>Obviously you are an armchair programmer since you are merely guessing. All that
>>will happen is this...

>> C:\>Hello
>> Hello World
>> C:\

>>Instead of...

>> C:\>Hello
>> Hello World

>> C:\

>>No guessing needed! Funny how the real world works like that, eh?

>Yeah, funny. There are any number of compilers/systems out there that
>won't display this output.

Name some then. Don't try IBM, MS, or Borland, as they work.

>>>Once the correct header is used, cout is placed in the std namespace,
>>>therefore it's full name is std::cout. It can either be referred to
>>>using this fully qualified name or the name can be brought into scope
>>>using a 'using' statement.

>>Or you can set it in some compilers to default to namespaces by default...which
>>most do.

>That sentence doesn't even make sense.

That's your problem.

>A standard-compliant compiler must issue a diagnostic for code that
>fails to properly qualify names, or bring them into scope with a 'using'
>statement.

You are just full of one excuse after another. No diagnostic is *required*
because it isn't *mandatory* that you use an int. You can ignore the value
returned if you don't need it, and still be compliant. Duh!

>>>Missing semi-colon after the one and only statement in main().

>>That's because it isn't required in all cases.

>It is in this case.

Just because you say so, eh? Haha! Get a clue man before posting a reply on a
topic you known nothing about next time...please?

Jonathan Mcdougall

unread,
Sep 15, 2003, 10:40:43 PM9/15/03
to

<snipped everything>

PLEASE! Know that every single post is kept on at least hundreds of
archive sites. People are using these resources for learning or
understanding. You are misinforming people.

I do not know what you are trying to prove, but please stop. Continue
that discussion privatly or stop. And this applies to everybody here.

It has lasted long enough.

Jonathan

Josh Sebastian

unread,
Sep 15, 2003, 10:53:14 PM9/15/03
to
On Mon, 15 Sep 2003 19:11:36 -0700, The_Sage wrote:

>>Reply to article by: Kevin Goodsell <usenet1.spa...@neverbox.com>
>>Date written: Mon, 15 Sep 2003 01:41:41 GMT
>>MsgID:<pN89b.3798$BS5....@newsread4.news.pas.earthlink.net>
>
>>>>Non-standard (actually old, pre-standard) header. <iostream.h> no
>>>>longer exists in C++. The replacement is <iostream>
>
>>>It isn't non-standard, is just isn't specified in the standard that way. It is
>>>on your hard drive as "iostream.h" and you can use it both ways, just one way is
>>>standard and the other is not.
>
>>My hard drive does not define what is and is not standard. Neither does
>>yours. <iostream.h> is not standard. Even when it is supplied with a
>>compiler it is probably not the same as <iostream>. Things have changed
>>since ARM C++.
>
> Whether it is a standard or not, it is acceptable. IBM, MS, and Borland all
> agree with my interpretation of the standard and not yours.

You have not "interpreted" the standard, you have chosen to ignore
it. Those compilers also compile C code. That doesn't mean that valid C is
always valid C++. Your logic is faulty.

The reason it works is because they didn't want to break old code. K&R C
is no longer valid C, and ARM C++ is no longer valid C++. Compilers still
support those outdated dialects for pragmatic reasons.

> All the standard says is that main() must return an integer,

No, that's not what it says. It says, "the return type of main must be
int". You defined main with a return type of void. That makes you wrong.

>>>But ISO C++ Standard (ISO/IEC 14882:1998) specifically requires main to
>>>return int although you *can* use void main() in IBM, WATCOM, or MS C++
>>>(as well as other) ISO compliant compilers.
>
>>Are you sure? The lack of a compiler error does not make it correct.
>
> Nor does it make it incorrect.

Your logical fallacy merely invalidates your argument. The wording of
the standard makes the code incorrect.

>>>http://homepages.tesco.net/~J.deBoynePollard/FGA/legality-of-void-main.html
>>
>>Wow, you can use a search engine.
>
> Wow, and you can't refute a simple search engine article.

The article to which you linked doesn't need to be refuted: it is 100%
correct. Perhaps you should read it. In case you are too lazy to click on
your own links, here's what it says, in bold, at the top:

"void main() is not legal in C++"

It then goes on to discuss why it is (sometimes) legal in C. But we
weren't talking about C -- we were talking about C++.

>>>>* The output may never be seen. This is not a problem with
flushing
>>>>(cout will be flushed when it is destroyed on program termination). It
>>>>is a problem with not properly terminating the line. A C++ program
>>>>should end it's output with a newline.
>
>>>Obviously you are an armchair programmer since you are merely guessing.
>>>All that will happen is this...
>
>>> C:\>Hello
>>> Hello World
>>> C:\
>
>>>Instead of...
>
>>> C:\>Hello
>>> Hello World
>
>>> C:\
>
>>>No guessing needed! Funny how the real world works like that, eh?
>
>>Yeah, funny. There are any number of compilers/systems out there that
>>won't display this output.
>
> Name some then. Don't try IBM, MS, or Borland, as they work.

Actually, it doesn't always work on Borland. The thing is, it /might/
work, but it's not /required/ to work. That's what "not correct" means. It
doesn't mean it will /always/ fail; it just means it won't always succeed.

>>>Or you can set it in some compilers to default to namespaces by
>>>default...which most do.
>
>>That sentence doesn't even make sense.
>
> That's your problem.

Your lack of command of the English language is no one's problem but your
own.



>>>>Missing semi-colon after the one and only statement in main().
>
>>>That's because it isn't required in all cases.
>
>>It is in this case.
>
> Just because you say so, eh? Haha!

What makes you think it's optional? Because you say so?

Josh

Greg Schmidt

unread,
Sep 15, 2003, 11:42:01 PM9/15/03
to
On Sun, 14 Sep 2003 18:09:49 -0700, The_Sage <thee...@azrmci.net>
wrote:

>It isn't non-standard, is just isn't specified in the standard that way. It is


>on your hard drive as "iostream.h" and you can use it both ways, just one way is
>standard and the other is not.

Some folks here may be interested to hear that I installed MS VS7.1
today, and iostream.h is *not* part of the installation. I found out
when I tried to compile some code (not mine) which used it, and failed.
TheSage will likely insist that my computer is in some parallel universe
or that I did something non-standard with my installation, but I assure
you that neither of these are true. Looks like MS VS7.1 is quite a bit
more standard-compliant (in this and other ways) than anything we've
seen from them before. Maybe I'll try the code that was posted and see
what output results...

Andrew Koenig

unread,
Sep 16, 2003, 10:26:28 AM9/16/03
to
C> I must admit to being rather surprised that a return with a value
C> can be implied, is this just for the main() procedure or does it
C> apply to all functions and if the latter, surely it would be good
C> practice to write the return anyway?

It's just for main, and it's a backward compatibility hack.
It's good practice to write the return anyway.

--
Andrew Koenig, a...@acm.org

Andrew Koenig

unread,
Sep 16, 2003, 10:40:02 AM9/16/03
to
>> My hard drive does not define what is and is not standard. Neither does
>> yours. <iostream.h> is not standard. Even when it is supplied with a
>> compiler it is probably not the same as <iostream>. Things have changed
>> since ARM C++.

TS> Whether it is a standard or not, it is acceptable. IBM, MS, and
TS> Borland all agree with my interpretation of the standard and not
TS> yours.

Your interpretation of the standard is incorrect. Here is what the
standard actually says:

Subclause 3.6.1, paragraph 2:

An implementation shall not predefine the `main' function.
This function shall not be overloaded. It shall have a return
type of type `int,' but otherwise its type is implementation-
defined. All implementations shall allow both of the following
definitions of `main':

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

and

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

When the C++ standard uses the word ``shall'' in this way, it
expresses a requirement on programs that every standard-conforming
implementation is required to enforce, at least by producing a
diagnostic message (which might be only a warning) for any program
that does not meet the requirement.

So, for example, if I try to compile the following program:

void main() { }

under g++ version 3.3.1, I get the following message:

prog.c:1: error: `main' must return `int'

That's what the standard says should happen.

In practice, many compilers allow `main' to return void. This
practice is not sanctioned by the standard, but probably does reduce
the number of complaints from users who have read books that
incorrectly claim that `main' is permitted to return void. Strictly
speaking, a compiler that permits `main' to return void does not
conform to the standard, and a customer that requires the compilers
they use to conform to the standard would be justified in rejecting
the compiler on those grounds.

In summary, if you tell me that `main' is permitted to return void
because the compilers you use happen to accept it, my response is:

1) The compiler I use doesn't accept it.

2) The C++ standard clearly says it's wrong.

3) Your compilers are not conforming to the standard.


Regards,


Andrew Koenig

The_Sage

unread,
Sep 16, 2003, 9:14:13 PM9/16/03
to
>Reply to article by: Josh Sebastian <cur...@cox.net>
>Date written: Mon, 15 Sep 2003 22:53:14 -0400
>MsgID:<pan.2003.09.16....@cox.net>

>>>>>Non-standard (actually old, pre-standard) header. <iostream.h> no
>>>>>longer exists in C++. The replacement is <iostream>

>>>>It isn't non-standard, is just isn't specified in the standard that way. It is
>>>>on your hard drive as "iostream.h" and you can use it both ways, just one way is
>>>>standard and the other is not.

>>>My hard drive does not define what is and is not standard. Neither does
>>>yours. <iostream.h> is not standard. Even when it is supplied with a
>>>compiler it is probably not the same as <iostream>. Things have changed
>>>since ARM C++.

>>Whether it is a standard or not, it is acceptable. IBM, MS, and Borland all
>>agree with my interpretation of the standard and not yours.

>You have not "interpreted" the standard, you have chosen to ignore
>it. Those compilers also compile C code. That doesn't mean that valid C is
>always valid C++. Your logic is faulty.

>The reason it works is because they didn't want to break old code.

No, that isn't the reason because neither IBM, MS, nor Borland give that as a
reason. They all state that their compiler is ISO compliant and they all agree
with my interpretation and disagree with yours.

Case closed.

Buster Copley

unread,
Sep 16, 2003, 9:17:11 PM9/16/03
to
> Case closed.

Idiot.

The_Sage

unread,
Sep 16, 2003, 9:28:13 PM9/16/03
to
>Reply to article by: Andrew Koenig <a...@acm.org>
>Date written: Tue, 16 Sep 2003 14:40:02 GMT
>MsgID:<yu99ad94...@tinker.research.att.com>

>>>My hard drive does not define what is and is not standard. Neither does
>>>yours. <iostream.h> is not standard. Even when it is supplied with a
>>>compiler it is probably not the same as <iostream>. Things have changed
>>>since ARM C++.

>TS>Whether it is a standard or not, it is acceptable. IBM, MS, and
>TS>Borland all agree with my interpretation of the standard and not
>TS>yours.

>Your interpretation of the standard is incorrect.

You mean, IBM, MS, Borland and other compiler manufacturer's interpretation of
the standard is incorrect.

>Here is what the standard actually says:

>Subclause 3.6.1, paragraph 2:

> An implementation shall not predefine the `main' function.
> This function shall not be overloaded. It shall have a return
> type of type `int,' but otherwise its type is implementation-
> defined. All implementations shall allow both of the following
> definitions of `main':

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

> and

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

>When the C++ standard uses the word ``shall'' in this way, it
>expresses a requirement on programs that every standard-conforming
>implementation is required to enforce, at least by producing a
>diagnostic message (which might be only a warning) for any program
>that does not meet the requirement.

>So, for example, if I try to compile the following program:

> void main() { }

>under g++ version 3.3.1, I get the following message:

> prog.c:1: error: `main' must return `int'

>That's what the standard says should happen.

The standard does not mention any error messages when using a different version
of main(). What the standard actually implies, and I quote research at ATT
concerning this topic...

"A conforming implementation accepts

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

and

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

A conforming implementation may provide more versions of main(),
but they must all have return type int"
(http://www.research.att.com/~bs/bs_faq2.html#void-main)

>In practice, many compilers allow `main' to return void. This
>practice is not sanctioned by the standard, but probably does reduce
>the number of complaints from users who have read books that
>incorrectly claim that `main' is permitted to return void.

On most of the major compilers, it is permitted, so the books are correct.

>Strictly
>speaking, a compiler that permits `main' to return void does not
>conform to the standard, and a customer that requires the compilers
>they use to conform to the standard would be justified in rejecting
>the compiler on those grounds.

Strictly speaking, it is conforming, it just isn't recommended because it may
not be portable, for example, GCC doesn't implement any other version of main()
other than the one suggested by the ISO standard.

>In summary, if you tell me that `main' is permitted to return void
>because the compilers you use happen to accept it, my response is:

> 1) The compiler I use doesn't accept it.

That proves nothing, as explained above.

> 2) The C++ standard clearly says it's wrong.

No it doesn't.

> 3) Your compilers are not conforming to the standard.

Yes they are.

Noah Roberts

unread,
Sep 16, 2003, 9:38:43 PM9/16/03
to
The_Sage wrote:
> The standard does not mention any error messages when using a different version
> of main(). What the standard actually implies, and I quote research at ATT
> concerning this topic...
>
> "A conforming implementation accepts
> int main() { /* ... */ }
>
> and
>
> int main(int argc, char* argv[]) { /* ... */ }
>
> A conforming implementation may provide more versions of main(),
> but they must all have return type int"

You are really bad at this aren't you...

In case you don't realize...this is exactly what everyone has been
trying to tell you. main() must return type int. You have just proven
yourself wrong :P

NR

Josh Sebastian

unread,
Sep 16, 2003, 10:02:47 PM9/16/03
to
On Tue, 16 Sep 2003 18:14:13 -0700, The_Sage wrote:

>>Reply to article by: Josh Sebastian <cur...@cox.net>
>>Date written: Mon, 15 Sep 2003 22:53:14 -0400
>>MsgID:<pan.2003.09.16....@cox.net>
>
>>>>>>Non-standard (actually old, pre-standard) header. <iostream.h> no
>>>>>>longer exists in C++. The replacement is <iostream>
>
>>>>>It isn't non-standard, is just isn't specified in the standard that way. It is
>>>>>on your hard drive as "iostream.h" and you can use it both ways, just one way is
>>>>>standard and the other is not.
>
>>>>My hard drive does not define what is and is not standard. Neither does
>>>>yours. <iostream.h> is not standard. Even when it is supplied with a
>>>>compiler it is probably not the same as <iostream>. Things have changed
>>>>since ARM C++.
>
>>>Whether it is a standard or not, it is acceptable. IBM, MS, and Borland all
>>>agree with my interpretation of the standard and not yours.
>
>>You have not "interpreted" the standard, you have chosen to ignore
>>it. Those compilers also compile C code. That doesn't mean that valid C is
>>always valid C++. Your logic is faulty.
>
>>The reason it works is because they didn't want to break old code.
>
> No, that isn't the reason because neither IBM, MS, nor Borland give that as a
> reason. They all state that their compiler is ISO compliant

No, they don't. They each list specific points where their compiler
is not compliant. Off the top of my head, none of them supports the export
keyword. Borland gave their implementation of the Standard Library less
than a 92% compliance rating:
http://bdn.borland.com/article/0,1410,29080,00.html

> and they all agree
> with my interpretation and disagree with yours.

They state their compilers are ISO compliant /with extensions/. A compiler
that was simply ISO compliant and nothing more wouldn't be very useful.
"With extensions" means that the compiler allows you to do things that the
rules of C++ do not allow. For example, the C++ rules for the
main() function can be found here:
http://oscinfo.osc.edu/software/docs/kaic/ANSI-Dec-1996/basic.html

Now, compare that to the MS Visual C++ rules for the main() function,
which can be found here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_program_startup.3a_.the_main_function.asp

Do you see the differences? Do you see how MS's rules are slightly
different than the Standard's rules? Just because you follow MS's rules
(and it compiles with MS's compiler) does not mean you've followed all the
rules of the Standard.

Josh

Josh Sebastian

unread,
Sep 16, 2003, 10:09:45 PM9/16/03
to
On Tue, 16 Sep 2003 18:28:13 -0700, The_Sage wrote:

>>Reply to article by: Andrew Koenig <a...@acm.org>

>>Your interpretation of the standard is incorrect.
>
> You mean, IBM, MS, Borland and other compiler manufacturer's interpretation of
> the standard is incorrect.

No. We're saying that IBM, MS, and Borland know that their compilers are
not perfectly compliant, and (for many conformance issues) they don't
care.

T.M. Sommers

unread,
Sep 16, 2003, 10:53:47 PM9/16/03
to
The_Sage wrote:
>>Reply to article by: Andrew Koenig <a...@acm.org>
>>Date written: Tue, 16 Sep 2003 14:40:02 GMT
>>MsgID:<yu99ad94...@tinker.research.att.com>
>
> The standard does not mention any error messages when using a different version
> of main(). What the standard actually implies, and I quote research at ATT
> concerning this topic...
>
> "A conforming implementation accepts
> int main() { /* ... */ }
>
> and
>
> int main(int argc, char* argv[]) { /* ... */ }
>
> A conforming implementation may provide more versions of main(),
> but they must all have return type int"
> (http://www.research.att.com/~bs/bs_faq2.html#void-main)

Did you read the two sentences before the one you quote? If not, here
they are:

The definition

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

is not and never has been C++, nor has it even been C. See
the ISO C++ standard 3.6.1[2] or the ISO C standard 5.1.2.2.1.

>>In summary, if you tell me that `main' is permitted to return void
>>because the compilers you use happen to accept it, my response is:
>
>> 1) The compiler I use doesn't accept it.
>
> That proves nothing, as explained above.
>
>> 2) The C++ standard clearly says it's wrong.
>
> No it doesn't.
>
>> 3) Your compilers are not conforming to the standard.
>
> Yes they are.

You do realize, don't you, that the Mr. Koenig you are contradicting
above is the project editor of the C++ standards committee?


Randall Hyde

unread,
Sep 16, 2003, 11:34:17 PM9/16/03
to

"T.M. Sommers" <tm...@mail.ptd.net> wrote in message news:%0Q9b.3288$yp6....@nnrp1.ptd.net...

> The_Sage wrote:
>
> You do realize, don't you, that the Mr. Koenig you are contradicting
> above is the project editor of the C++ standards committee?

What are you C++ guys complaining about?
Mr. "The_Sage" cannot even differentiate assembly code and C code
(he insists that an assembly language file I uploaded a while back was
a C file and continues to claim that I am "lying" when I claim otherwise).

Seriously, though, we all need to cut Mr. "The_Sage" some slack here.
He is clearly in need of some serious help and the continuous negative
feedback we are giving him is just causing him to sink deeper and deeper
into the depths of mental illness (specfically, ignoring reality, as acknowledging
reality would require him to admit that he is wrong, something he very *rarely*
does).

We should all take pity on him and just ignore him.
Cheers,
Randy Hyde


Jerry Coffin

unread,
Sep 17, 2003, 1:46:45 AM9/17/03
to
In article <lodfmv0i4u7igamib...@4ax.com>,
thee...@azrmci.net says...

[ ... ]

> >Your interpretation of the standard is incorrect.
>
> You mean, IBM, MS, Borland and other compiler manufacturer's interpretation of
> the standard is incorrect.

That's not the correct conclusion at all. To quote from section 1.4/8
of the standard:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter
the behavior of any well-formed program. Implementations
are required to diagnose programs that use such extensions
that are ill-formed according to this international standard.
Having done so, they can compile and execute such programs.

In addition to that, most compilers require very specific usage to run
in their (most) conforming mode. In other modes, they may (for example)
accept programs that are ill-formed according to the standard, without
any diagnostics at all.

In short, the fact that you've used a couple of compilers and they
accept the code means precisely and exactly NOTHING about whether your
code is correct.

[ ... ]

> The standard does not mention any error messages when using a different version
> of main().

Quite the contrary -- you simply have to learn how to read the standard
as a whole instead of ignoring the parts that don't suit what you'd like
to believe.

> What the standard actually implies, and I quote research at ATT
> concerning this topic...

The standard does not imply -- it states quite specifically that at
least one diagnostic is required for any program that violates a
syntactic rule or a diagnosable semantic rule of the standard.

[ ... ]



> On most of the major compilers, it is permitted, so the books are correct.

That depends on whether the books purport to teach C++, or "whatever
most major compilers accept".

[ ... ]



> > 2) The C++ standard clearly says it's wrong.
>
> No it doesn't.

Yes, it most assuredly does.

> > 3) Your compilers are not conforming to the standard.
>
> Yes they are.

Regardless of this particular part, they most assuredly are NOT. I'm
reasonably certain that there is only one C++ compiler today that can
honestly make ANY claim to conforming with the standard (and that's from
Comeau). Every other C++ compiler around has well-known and major
omissions in its implementation of C++. You've listed IBM, MS and
Borland above as your compilers, and here you're claiming that they
conform. If you look at:

http://msdn.microsoft.com/chats/vstudio/vstudio_022703.asp

You'll find a rather lengthy interview, in which a number of MS
employees openly state that MS' current compiler is NOT a conforming
implementation of C++.

At:

http://ww6.borland.com/plumhall/phq.exe/ShowTable

You'll find Borland's own statement that their most recent compiler is
NOT a conforming implementation of C++. From their viewpoint, it's a
good thing that their compiler passes almost 92% of the tests in the
Plum-Hall validation suite (and I tend to agree that this is quite
good). From any viewpoint, however, 92% is not the same as 100% -- a
100% is the point at which you can start to argue that it MIGHT be a
conforming implementation. Anything less than 100% means that they know
full-well that the implementation doesn't conform.

--
Later,
Jerry.

The universe is a figment of its own imagination.

David B. Held

unread,
Sep 17, 2003, 3:48:29 AM9/17/03
to
"The_Sage" <thee...@azrmci.net> wrote in message
news:lodfmv0i4u7igamib...@4ax.com...
> [...]

> You mean, IBM, MS, Borland and other compiler
> manufacturer's interpretation of the standard is incorrect.

Given the way you "interpret" standards, I must conclude that
you are not a programmer, and that any well-formed programs
that you do write must be the result of a mind-bogglingly
improbably accident comparable to a thousand monkeys
randomly producing the entire works of Shakespeare on
typewriters.

> Strictly speaking, it is conforming, it just isn't recommended

What isn't recommended is you going near a C++ compiler.

> because it may not be portable,

Someone who defies the standard itself, and then quotes the
draft standard as support, and then continues arguing that
"void main()" is legal C++ is utterly unqualified to speak an
iota about portability.

> for example, GCC doesn't implement any other version of
> main() other than the one suggested by the ISO standard.

All the other forms of main() allowed by the ISO standard
have a return type of int.

> [...]


> > 2) The C++ standard clearly says it's wrong.
>
> No it doesn't.

Ok, so here we have it:

1) C++ Standard, specifying the return type of main()
2) interpreters of the standard, who disagree on 1)

One of the interpreters is a C++ committee member, an
author of an acclaimed C++ book, an internationally
recognized C++ expert, and has a language feature named
after him. The other signs his posts with an alias (unless
"The Sage" is his/her legal name), has no known publications,
is an internationally recognized crank, and wouldn't be
allowed on the C++ committee if he paid everyone else's
dues. I wonder which one is more qualified to determine
whether the standard allows main() to return void? This
is a difficult and vexing question...hmm...

> > 3) Your compilers are not conforming to the
> > standard.
>
> Yes they are.

And that, of course, is because "conforming" means "what
my compiler does". Which is why we write standards. To
describe what compilers *do*, not what they are
*supposed* to do. I see. It all makes sense. Anyone
else want a hit on the bong?

> The Sage

Now, I have a proof that this crackpot is none other than
the convener of the C++ committe himself! See, the casual
reader would assume that "sage" means "wise". But it doesn't
take a rocket scientist to see that no wisdom can be found in
the words of this poster, which means we are forced to
conclude that "sage" means "herb"...hmm..."The herb"...
which might explain the inspiration for his ideas, but is a
tangential issue at best. No, there is only *one* "herb"
when it comes to C++, and that's "herb" Sutter! He's just
yanking everyone's chain and having a laugh at our expense!

> [...]


> "The men that American people admire most extravagantly
> are most daring liars; the men they detest the most violently
> are those who try to tell them the truth" -- H. L. Mencken

I really admire the way you defend your position. Oh, and
"audacious" != "brave bearer of truth". After all, fools rush in
where angels fear to tread.

Dave


The_Sage

unread,
Sep 17, 2003, 8:45:18 PM9/17/03
to
>Reply to article by: Noah Roberts <nrob...@dontemailme.com>
>Date written: Tue, 16 Sep 2003 18:38:43 -0700
>MsgID:<3F67BB2...@dontemailme.com>

>> "A conforming implementation accepts
>> int main() { /* ... */ }

>> and

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

>> A conforming implementation may provide more versions of main(),
>> but they must all have return type int"

>You are really bad at this aren't you...

>In case you don't realize...this is exactly what everyone has been
>trying to tell you. main() must return type int. You have just proven
>yourself wrong :P

The standard says you must return int, which all ISO compliant compilers do, BUT
IT ALSO STATES YOU CAN RETURN OTHER THINGS AS WELL. You just proved you are
illiterate.

The_Sage

unread,
Sep 17, 2003, 8:49:25 PM9/17/03
to
>Reply to article by: Josh Sebastian <cur...@cox.net>
>Date written: Tue, 16 Sep 2003 22:09:45 -0400
>MsgID:<pan.2003.09.17....@cox.net>

>>You mean, IBM, MS, Borland and other compiler manufacturer's interpretation of
>>the standard is incorrect.

>No. We're saying that IBM, MS, and Borland know that their compilers are
>not perfectly compliant, and (for many conformance issues) they don't
>care.

Quotes please, that way we can see if you are making this all up as you go along
just so you can win an argument, or if IBM, MS, and Borland are all on the
record as saying, "Yes, we violated the ISO standard but we don't care, we are
going to call it ISO compliant anyway". I await your proof.

The_Sage

unread,
Sep 17, 2003, 8:53:24 PM9/17/03
to
>Reply to article by: "T.M. Sommers" <tm...@mail.ptd.net>
>Date written: Wed, 17 Sep 2003 02:53:47 GMT
>MsgID:<%0Q9b.3288$yp6....@nnrp1.ptd.net>

>>The standard does not mention any error messages when using a different version
>>of main(). What the standard actually implies, and I quote research at ATT
>>concerning this topic...

>> "A conforming implementation accepts
>> int main() { /* ... */ }

>> and

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

>> A conforming implementation may provide more versions of main(),
>> but they must all have return type int"
>> (http://www.research.att.com/~bs/bs_faq2.html#void-main)

>Did you read the two sentences before the one you quote? If not, here
>they are:

> The definition

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

> is not and never has been C++, nor has it even been C. See
> the ISO C++ standard 3.6.1[2] or the ISO C standard 5.1.2.2.1.

And did you stop there are did you continue on to where it amended that
statement with:

A conforming implementation may provide more versions of main(), but they must

all have return type int.

In case you can't read, it means that void main() was never specified but it can
be if you so choose to do so, just so long as you always have int main() as one
of your implementations.

It is plain and simple:

1) void main() is not defined by the ISO standard but
2) void main() is compliant

The_Sage

unread,
Sep 17, 2003, 8:56:22 PM9/17/03
to
>Reply to article by: Jerry Coffin <jco...@taeus.com>
>Date written: Wed, 17 Sep 2003 05:46:45 GMT
>MsgID:<MPG.19d1a34a6...@news.clspco.adelphia.net>

>>>Your interpretation of the standard is incorrect.

>>You mean, IBM, MS, Borland and other compiler manufacturer's interpretation of
>>the standard is incorrect.

>That's not the correct conclusion at all. To quote from section 1.4/8
>of the standard:

> A conforming implementation may have extensions (including
> additional library functions), provided they do not alter
> the behavior of any well-formed program. Implementations
> are required to diagnose programs that use such extensions
> that are ill-formed according to this international standard.
> Having done so, they can compile and execute such programs.

Using void main() does not alter the behavior of any well-formed program and the
compilers all have debuggers which recognize void main() as ISO compliant and
well-formed.

>In addition to that, most compilers require very specific usage to run
>in their (most) conforming mode. In other modes, they may (for example)
>accept programs that are ill-formed according to the standard, without
>any diagnostics at all.

>In short, the fact that you've used a couple of compilers and they
>accept the code means precisely and exactly NOTHING about whether your
>code is correct.

We aren't talking about whether the code is correct here, but whether it is ISO
compliant.

Try again.

Sam Holden

unread,
Sep 17, 2003, 9:18:13 PM9/17/03
to
On Wed, 17 Sep 2003 17:53:24 -0700, The_Sage <thee...@azrmci.net> wrote:
>
> And did you stop there are did you continue on to where it amended that
> statement with:
>
> A conforming implementation may provide more versions of main(), but they must
> all have return type int.
>
> In case you can't read, it means that void main() was never specified but it can
> be if you so choose to do so, just so long as you always have int main() as one
> of your implementations.
>
> It is plain and simple:
>
> 1) void main() is not defined by the ISO standard but
> 2) void main() is compliant

Do you know the meaning of the words "all" and "must"?

"they must all have return type int" means exactly what it says.

It doesn't mean one must have return type int, or some must have return
type int. It means *all* must have return type it.

It doesn't mean all may have return type int, it means all *must* have
return type int.

Not being able to code a "hello world" program I can understand. Many
people have trouble with such things. However, the words "all" and
"must" are understood by most (I would have said all, but you would have
been a counter example) three year olds.

--
Sam Holden

The_Sage

unread,
Sep 17, 2003, 10:08:35 PM9/17/03
to
>Reply to article by: "David B. Held" <dh...@codelogicconsulting.com>
>Date written: Wed, 17 Sep 2003 02:48:29 -0500
>MsgID:<bk93nh$jk$1...@news.astound.net>

>>You mean, IBM, MS, Borland and other compiler
>>manufacturer's interpretation of the standard is incorrect.

>Given the way you "interpret" standards, I must conclude that
>you are not a programmer, and that any well-formed programs
>that you do write must be the result of a mind-bogglingly
>improbably accident comparable to a thousand monkeys
>randomly producing the entire works of Shakespeare on
>typewriters.

Given the way you cannot support anything you claim with facts or references or
logic, I must conclude you are a total idiot.

The Sage

=============================================================
My Home Page : http://members.cox.net/the.sage

"The men that American people admire most extravagantly are


most daring liars; the men they detest the most violently are
those who try to tell them the truth" -- H. L. Mencken

=============================================================

Randall Hyde

unread,
Sep 18, 2003, 1:33:21 AM9/18/03
to

"Sam Holden" <sho...@flexal.cs.usyd.edu.au> wrote in message news:slrnbmi1ul....@flexal.cs.usyd.edu.au...

>
> Do you know the meaning of the words "all" and "must"?
>
No. He doesn't.
I've constantly pointed out to Mr. "The_Sage" that he doesn't
know the difference between a universal quantifier and an
existential quantifier (you missed the whole discussion where
he insisted that everyone else's arguments suffered from
"logical fallacies" and I quickly pointed out the logical fallacies
of his own arguments).

Bottom line, he just loves to argue. Doesn't matter whether
he's right or wrong. No, I take that back, it's much better
if he's wrong 'cause that gets even more people all worked
up over his ridiculous statements.
Randy Hyde

Cute comic about trolls:
http://www.pvponline.com/archive.php3?archive=20030915


Randall Hyde

unread,
Sep 18, 2003, 1:37:38 AM9/18/03