The worst 'hello world' example ever written...
C
> >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
> 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
> 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.)]
The guy is either a troll or a simpleton. Just ignore him.
--
WW aka Attila
Kevin Goodsell
>
>
> [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
> 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
>
> <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
> 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
>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
>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
>>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
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
>
>>>>>> #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
[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
[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
>
> 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
"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
"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
>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
<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
>>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
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
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
>> 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
>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
Idiot.
The_Sage
>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
> 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
>>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
>>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
>>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>
>
> 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
"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
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
> [...]
> 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
>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
>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
>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
>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
>
> 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
>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
"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"?
>
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
"David B. Held" <dh...@codelogicconsulting.com> wrote in message news:bk93nh$jk$1...@news.astound.net...
> 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.
Yeah, on top of that he claims that the author of no less than
three books on assembly language, who has also taught
assembly language at the University (UC) level for over
a decade, submitted some C code and attempted to call it
assembly language. :-) (that would be your's truly.)
Who ya gonna' believe?
Cheers,
Randy Hyde
Randall Hyde
"The_Sage" is making everyone look like idiots!
It's wonderful how warped his mind is.
He posts some code and argues about how correct
it is known *damn* well no one will try and compile
it to see what happens!
It's amazing how long this argument has been going
on and no one as bothered to call him on the point
that he is simply *lying* about the fact that Borland C++
will compile that code without that semicolon at the
end of the "cout" expression.
Okay, here's the code:
#include <iostream.h>
void main()
{
cout << "Hello, World!"
}
Here's what I get when I run it through BCC32 (v5.0)
g:\>bcc32 hw.cpp
Borland C++ 5.0 for Win32 Copyright (c) 1993, 1996 Borland International
hw.cpp:
Error hw.cpp 5: Statement missing ; in function main()
Error hw.cpp 5: Compound statement missing } in function main()
*** 2 errors in Compile ***
Now, you'll have to forgive me for having such an old version
of the compiler. Maybe they introduced this "bug" into their
compiler in a later version (i.e., BCC32 v5.5 or later).
However, it sure looks to me like Borland C++ v5.0 chokes on the
missing semicolon.
Oh, Microsoft VC++?
Well, I must admit I'm only running v12.00.8804, but here's what
it returns:
g:\>vcvars32
Setting environment for using Microsoft Visual C++ tools.
g:\>cl hw.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
hw.cpp
hw.cpp(5) : error C2143: syntax error : missing ';' before '}'
Sorry, I don't have the IBM compiler, so I can't try that one out.
In any case, I'm sure that "The_Sage" is laughing his behind off
because he's had this argument going on for quite some time based
totally on a lie; I bet he's real amused that everyone fell for this
nonsense of his, hook, line, and sinker (not that a semicolon is valid,
but that Borland and MS compilers would actually accept this nonsense).
Hopefully, this puts an end to this junk and he can go back to claiming
that my HLA (assembly) code is really C (I haven't found a C compiler
that accepts it yet, Borland, MS, IBM, or otherwise...).
Cheers,
Randy Hyde
David B. Held
> >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-
> >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.
To introduce any more facts would be an insult to the
numerous people who have already provided more than
ample evidence to soundly refute your ridiculous claim. I
just wanted to add insult to injury, because cranks like you
cannot be reasoned with. Speaking of evidence, I defy you
to cite one reference from IBM, Microsoft, or Borland
claiming that *any* version of *any* C++ compiler they
have produced is 100% ISO/ANSI compliant. If you are
unable to produce such documentation, I demand an
admission of error from you, or an apology for attempting
to foist fraud upon us.
Dave
David B. Held
> [...]
> 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,
Obviously, you're the one that can't read.
> it means that void main() was never specified
Absolutely false. Let's review:
A conforming implementation may provide more
versions of main(), but
THEY MUST ALL HAVE RETURN TYPE INT
Which part of "all" DOESN'T include "void main()"?
> 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.
What universe did you come from? I don't think the most
clueless non-English speaking person could possibly parse
the standard that way.
> It is plain and simple:
Yes it is, which is all the more embarrassing for you.
> 1) void main() is not defined by the ISO standard
*BUT*, it is *referred to* in the ISO standard as being
ILL-FORMED, since it DOES NOT HAVE RETURN
TYPE INT.
> but
> 2) void main() is compliant
Only in your little dream world. If every member of the
C++ committee (meaning, the people who WROTE the
standard) and Bjarne Stroustrup himself all visited you at
home and told you that the standard prohibited "void main()"
in well-formed programs, would you believe them, or tell
them to: "sod off, because IBM, M$, and Borland disagree
with you bloody wankers"? To put it another way, is there
any evidence that could theoretically be shown to you that
would convince you that you might be wrong?
Dave
arargh3...@now.at.arargh.com
<dh...@codelogicconsulting.com> wrote:
<snip>
>Only in your little dream world. If every member of the
>C++ committee (meaning, the people who WROTE the
>standard) and Bjarne Stroustrup himself all visited you at
>home and told you that the standard prohibited "void main()"
>in well-formed programs, would you believe them, or tell
>them to: "sod off, because IBM, M$, and Borland disagree
>with you bloody wankers"? To put it another way, is there
>any evidence that could theoretically be shown to you that
>would convince you that you might be wrong?
Perhaps a 2x4 upside the head? Repeat as necessary. :-)
--
Arargh309 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
Attila Feher
> The standard says you must return int, which all ISO compliant
> compilers do, BUT IT ALSO STATES YOU CAN RETURN OTHER THINGS AS WELL.
No, it does not. 3.6.1 Main function paragraph 2:
"*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[]) { /* ... */ }
"
continuing with
"The function main shall not be used (3.2) within a program. The linkage
(3.5) of main is /implementation-defined/."
For those who can read and understand (not you Rage, opps Sage) it says:
The main function must have the return type int. However you are not
allowed to call it so this int is for the implementation not you. The rest
of the function signature can be whatever the implementers define *but* it
must define the above two full signatures as valid.
> You just proved you are illiterate.
Nope Sage. You have just proved that not only you are clueless and
arrogant, but it is also hopeless for you to ever change.
--
Attila aka WW
Attila Feher
>> 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 proof is in my previous post. And I am sorry to inform you but we are
not here to argue you, a hopelessly lost mind, but to help those who have
the ability to listen. In any case if you need any further accurate
information about the C++ language please see the FAQ for the URL of thew
ANSI store and get one for yourself. It is 18USD. Once you have read it
you might have a slight chance you will know what you are talking about. So
far all of your "proof" was a pathetic, ridiculous frustrated hysteria,
kinda along the lines of what 6 years old do when mom says we will not buy
chocolates today.
--
Attila aka WW
Attila Feher
> 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.
No. Again the standard:
3.6.1 paragraph 1 and two combined for the mentally impaired to form two
simple sentences, what even Sage can understand:
"A program shall contain a global function called main, which is the
designated start of the program. It shall have a return type of type int."
Plain and simple. main must return int. What arguments it can take is up
to yours truly the implementation. But its return value _must_ be int. It
is also pretty clear from the further requirements the standard puts on the
implementation regarding the main function:
3.6.1 para 5
"A return statement in main has the effect of leaving the main function
(destroying any objects with automatic storage duration) and calling exit
with the return value as the argument."
The exit() function takes an int argument. So if main would not return int
its return value could not be used with exit(). But wait, there is more to
prove you completely wrong:
Same paragraph:
"If control reaches the end of main without encountering a return statement,
the effect is that of executing
return 0;"
Got it? return 0; In a void function you cannot write return 0;
> It is plain and simple:
>
> 1) void main() is not defined by the ISO standard but
Correct. It is not defined since it cannot not exist in a standard
conforming program.
> 2) void main() is compliant
Incorrect.
void main() is not per se defined by the standard but *all* main functions
returning *anything else* than int are defined as non-conforming.
Sage: stop trolling
http://info.astrian.net/jargon/terms/t/troll.html
--
Attila aka WW
Attila Feher
> 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.
Debuggers have no freakin' clue about ISO compliance. The ISO/IEC C++
standard does not define or deal with debuggers. You are absolutely
clueless.
> We aren't talking about whether the code is correct here, but whether
> it is ISO compliant.
It is not. Look at the standard or just get a decent compiler.
http://www.comeaucomputing.com/techtalk/#voidmain
http://www.comeaucomputing.com/tryitout/
ComeauTest.c(1): error: return type of function "main" must be "int"
So use int main() OR int main(int argc, char *argv[])
void main() {}
^
--
Attila aka WW
Attila Feher
> references or logic, I must conclude you are a total idiot.
Sage, you have crossed that very line, which is not to be crossed.
--
Attila aka WW
Phil Carmody
Half a dozen troll posts a day, every day, which included telling
highly respect mebers of the C++ standardisation committee that they
didn't know anything about C++, and generally just being stupid
and obnoxious.
The Sage, troll =
Hello targets
Phil
Josh Lessard
> all have return type int.
>
>
> 1) void main() is not defined by the ISO standard but
> 2) void main() is compliant
I'm sorry, I just couldn't sit back and watch you make a jackass of
yourself any longer without saying anything.
My god you're an idiot. What part of "they must all have return type
int" don't you understand?? You just defeated your own argument, and
proved that you don't possess the comprehension skills required to
actually understand what is being written in the ISO C++ Standard. You
have no business trying to make an argument, either for or against the
Standard.
Read the sentence again. "A conforming implementation may provide more
versions of main(), but they *MUST* all have return type *int*." In other
words, if you provide a version of main() that does *NOT* have return type
int (eg double, float, *void*), then your implementation is *NOT*
conforming...it is *NOT* compliant.
Thus, void main() is *NOT* compliant because it does *NOT* have return
type int. Case closed, using your very own quote.
Now please...just go away and stop wasting the time and bandwidth of those
of us that have the desire to learn and the common sense and decency to
admit it when we're actually wrong.
*****************************************************
Josh Lessard
Master's Student
School of Computer Science
Faculty of Mathematics
University of Waterloo
(519)888-4567 x3400
http://www.cs.uwaterloo.ca
*****************************************************
Jerry Coffin
thee...@azrmci.net says...
[ ... ]
> > 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.
You're getting things entirely backwards: they're talking about the
requirements on the _implementation_. Anybody with an IQ above room
temperature (which apparently doesn't include you) realizes that what
you do in your program can't possibly affect what the compiler does with
other programs. Likewise, a debugger has nothing to do with any of this
at all -- your even mentioning it shows nothing more than the abysmal
depths of your ignorance of programming general.
No properly functioning compiler will "recognize void main() as ISO
compliant and well-formed". First of all, the ISO standard explicitly
states that conformance applies ONLY to implementations, NOT the your
source code. Second, as mentioned above, a conforming implementation
may accept your code, but (when run in conforming mode, of course) must
provide a diagnostic for it -- in the case of gcc, that's an error
message. In the case of MS, the "conforming mode" (or the closest it
has anyway) would be when it diagnoses a void return from main -- which
it can and will do.
None of this, however, changes the fact that none of the compilers
you've mentioned is (even close to) conforming. Therefore, the fact
that they have some mode in which they accept your code means absolutely
_nothing_ about the code being well-formed. The standard says it's not
well-formed, so it's not. As mentioned above, the standard also says
that a conforming implementation can reject it, OR it can accept it --
but even if it does accept the code, the compiler must issue a
diagnostic.
I realize that you have a vested interest in not looking like an idiot,
but you're honestly not helping your cause this way: you long ago hit
what most would have considered rock bottom -- you don't need to prove
that you CAN dig yourself in even deeper.
[ ... ]
> We aren't talking about whether the code is correct here, but whether it is ISO
> compliant.
The correct word is "conforming" not "compliant". It's a meaningless
term in this case though: the standard specifically states that its
requirements are only on implementations, not on source code. Even when
a requirement looks like it's on source code, it's still really a
requirement on the implementation, about accepting, rejecting,
diagnosing, etc.., that particular input.
A term that is meaningful about source code, however, is well-formed.
Your's is not. Therefore, a conforming implementation is not obliged to
accept that source code. If a conforming implementation does accept the
source code, a diagnostic must still be issued.
You have tested the code with a number of compilers, and they've
(apparently) accepted the code without diagnostics. This proves only
that, at least as you've run them, those compilers are not conforming
implementations of C++.
That's not news though: first of all, every compiler on the planet but
one is _known_ with certainty (by those of us who have a clue) to be
non-conforming (Comeau C++ is the _sole_ exception that might be a
conforming implementation of C++).
Second, even when you use a compiler that's _capable_ of conforming,
that doesn't mean it always conforms -- Comeau C++ has a number of
switches to allow it to operate in non-conforming modes so it will
accept code that's written (for example) for various other non-
conforming implementations.
Mike Smith
> 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.
Don't be silly. It is, for instance, well-known that MS compilers
accept the following:
#include <iostream>
for (int i = 0; i < 10; ++i)
{
std::cout << i << std::endl;
}
// i should be out of scope here!
std::cout << i << std::endl;
i should go out of scope when then for-loop exits, but an MS compiler
will print the final "10". This violates the Standard.
--
Mike Smith
Mike Smith
>
> 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.
Wrong! *All* versions of main() must return int. It says so in plain
English; you just typed it yourself! What can vary are the *parameters*
to main().
--
Mike Smith
Mike Smith
>
> 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.
No, they *recognize* it. That does not mean they recognize it as
*compliant*, which it isn't.
> We aren't talking about whether the code is correct here, but whether it is ISO
> compliant.
That's true. It is neither correct nor compliant.
--
Mike Smith
Mike Smith
>
> Speaking of evidence, I defy you
> to cite one reference from IBM, Microsoft, or Borland
> claiming that *any* version of *any* C++ compiler they
> have produced is 100% ISO/ANSI compliant.
MS, in fact, openly refers to their latest C++ compiler as "98% compliant".
http://msdn.microsoft.com/visualc/productinfo/overview/whatsnew.aspx
"With 98-percent conformance, Visual C++ .NET 2003 is more conformant to
ISO C++ standards than any previous version of Visual C++, and it
contains new language support for features including Koenig Lookup and
Partial Template Specialization."
--
Mike Smith
Mike Smith
>
> In any case, I'm sure that "The_Sage" is laughing his behind off
> because he's had this argument going on for quite some time based
> totally on a lie; I bet he's real amused that everyone fell for this
> nonsense of his, hook, line, and sinker (not that a semicolon is valid,
> but that Borland and MS compilers would actually accept this nonsense).
I don't think that anyone here thought for one second that either
Borland or MS would compile that example.
--
Mike Smith
Attila Feher
> The_Sage wrote:
>> references or logic, I must conclude you are a total idiot.
>
> Sage, you have crossed that very line, which is not to be crossed.
Do I see right that Sage somehow got cut off this newsgroup?
--
Attila aka WW
Kevin Goodsell
Where do you see that? I'm not aware of any way for that to actually
happen (but then, I don't know that much about the functioning of usenet).
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Attila Feher
>>>> references or logic, I must conclude you are a total idiot.
>>>
>>> Sage, you have crossed that very line, which is not to be crossed.
>>
>>
>> Do I see right that Sage somehow got cut off this newsgroup?
>
> Where do you see that?
He was posting a lot, now he does not. BTW observe the wuestion mark.
> I'm not aware of any way for that to actually happen.
One possibility is when one keeps calling people idiots on the usenet and
ones service provider decides to stop providing the service.
--
Attila aka WW
Beth
> 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.
Hmmm, maybe it's because we're all assembly language posters over here
who hate "automatic" anything and insist on everything being
_explicitly_ defined...but, well, that seems a dodgy thing to add to
either language...adding special exceptional behaviours...
Surely, if there's lots of C / C++ coders who are not putting in the
"return 0;" then it would be better to consider that an _error_ - to
force them to learn to do it properly - rather than adding this
implied behaviour to "main" as some exceptional behaviour...that cuts
into the consistency of the language, surely, to add lots of "it's
like this but not like that but like this if this is true but not
this" rules into it...
Make the lack of a "return" an _error_ and then you introduce the good
habit of always specifying it into the C / C++ coder's
vocabulary...tolerating mistakes actually only ends up leading to
further mistakes...nip those potentially buggy things in the bud,
soonest possible..._prevention rather than cure_ should always be
preferred, in my opinion...
Heck, you lot have actually got a compiler tool that actually is able
to _pick these things up_, unlike us ASM lot who have to do it all
manually...surely, it makes sense to take advantage of your available
advantages? :)
Beth :)
Beth
> 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.
Ah, the dreaded "backwards compatibility" forever haunting you with
design mistakes from the 1950s (okay, 1970s in C's case :)...the
"undead" zombie that refuses to lie still in its grave and finally
perish, like something out of Buffy the Vampire Slayer...
Oh, in which case, ignore the other post I made about making it an
error...let me guess: It can't be done because original K&R C syntax
allowed it and, thus, forever more, it must be allowed...even if it
was the grossest, most evil design mistake ever made in computing
history...such is "backwards compatibility", I know...there's nothing
much you can do about it...an "all or nothing" decision...maintain
everything that has ever been - on the off-chance some still has
source code for a Z80 running CP/M that they _insist_ on still
compiling "as is", rather than bringing it up to date with a simple
"return 0;" addition - or give it all up, which is, apparently, asking
too much...
Understood; It can't be made into an error because, at some point in
the ancient, dusty past, it was declared "okay" and that decision has
to be maintained through "backwards compatibility" until the seas boil
on Judgement Day...
Personally, when given the option, I'd suggest "lateral compatibility"
rather than its haunting cousin "backwards compatibility"...that is,
_convert_ old data into new data - using an appropriate utility - and
then work with the new data exclusively...indeed, many would frown and
say "but that's extra hassle!"...granted, I won't pretend
otherwise...but it's nothing compared to the hassle of maintaining all
those skeletons in the closet and being forever haunted by design
decisions made decades earlier...having to walk around with a ball and
chain forever shackled to your ankles...all innovation forever stifled
to "comply" with earlier '60s standards that were probably invented
whilst high on copious amounts of LSD or something...
The options: Pay it all off now in one "lump sum" payment and be
forever Liberated thereafter...or, continually pay "rent" over and
over and over, never being free of your debts to the past because they
refuse to let go...
Immediate short-termism or gradual long-termist Liberation: _You_
decide...
Beth :)
Beth
haunt our group...that is, a troll who does know a little something
about various topics and posts the odd legitimate thing to tempt
people to make honest response, before launching into outright
troll-ness...producing such wonders as that "main" function...and,
actually, that's comparatively bug-free compared to some of the
nonsense he's come out with on occasion...
He's a difficult troll to deal with because if it were all outright
nonsense then he's easily kill-filed and ignored...but as he fishes
with the odd legitimate comment now and again, he manages to reel the
odd fish in on his line before becoming a troll all over
again...hence, large threads develop from his original comments that
fill up the group...
Anyway, we're incredibly lax about "off-topicness" in
alt.lang.asm...there's also a moderated group too and, thus,
"alt.lang.asm" becomes the area for slightly more than average
"off-topicness" for things that would never pass the moderator on the
other assembly group...a nice arrangement _until_ trolls like this
"Sage" appear...to be honest, I think the "embarass him and Hope he'll
go away" strategy probably won't work on him, as I suspect he's doing
this very delibrately in a "sophisicated troll" way...but, well, it's
worth a try, at least...
Beth :)
P.S. Also, pardon the "off-topicness" from me too...I'll depart now
and not offend you any longer...just the clarification seemed to also
need clarification...or maybe that's just me...whatever...
Beth
> > Kevin Goodsell wrote:
> >* 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.
Note to people joining through cross-posting: This is typical Sage
"logical fallacy" for you here:
"It isn't non-standard"...and, yet, "one way is standard and the other
is not"...umm, so the way that's "not standard" somehow "isn't
non-standard"? Sage seems to be having problems with a simple double
negative here...
Does this guy comprehend the basics of the English language? I think
not ;)
[ By the way, I quote "logical fallacy" because, amazingly, despite
repeatedly producing such twisted logic, he's got this thing about
complaining that everything he hears is a "logical fallacy"...but,
yet, somehow, he can't detect his own logical fallacies in his own
words...I'm still not sure if this is part of his "troll" tactics - to
provoke reactions - or whether he really is this brain-dead in
reality... ]
Beth :)
P.S. When you corner him, he'll start swearing and calling you names
and launching a personal attack...just to give you forewarning to
expect this vulgar conduct and not to take it too personally, as he'll
do it to _anyone_ who starts to prove that he's talking complete
nonsense...
P.P.S. Actually, "C", perhaps it was unwise and not terribly clever to
cross-post the Sage over to other groups...we wouldn't want to have
him "spread" and "infect" other groups...he's bad enough in ours that
we can't wish him upon anyone else...
Beth
> 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.
Have you actually tried setting the "strict ANSI compliance" switch -
or whatever it's called on your particular tool - on these compilers
before compiling? Every compiler implementation is permitted some
"leeway" that's non-standard and the odd "proprietary extension"...
Please set this switch on those compilers and tell us of the
results...then realise that only that which is in the standard can be
relied upon to be truly "portable"...then realise you're wrong...then
shut up...then go away...though, if you like, you can just jump
straight to the "go away" step and save everyone a lot of time and
hassle...
Beth :)
Beth
> The_Sage wrote:
> >
http://homepages.tesco.net/~J.deBoynePollard/FGA/legality-of-void-main
.html
>
> Wow, you can use a search engine.
Actually, I find this slightly amusing so let me translate for my
American cousins...Sage's important "official" authoritative source
here is being hosted on a "cheap and cheerful" supermarket chain's
free hosting service..."Tesco.net" could be translated to "K-Mart.net"
or "7-11.net", if you like...not that being hosted by a supermarket
chain means the information is automatically inaccurate...but, well,
it does not bode well for the authority of the information...as this
stuff is free hosting from the supermarket's ISP side-business (they
also do loans and cars...a most versatile superstore, indeed
:)...thus, basically, _ANYONE_ could have got this webspace and put up
anything at all they liked...
The old sage advice: "Don't believe everything that's written in black
and white...even less so, when it's on the internet"...obviously,
though, this isn't this particular Sage's advice...he'll grab the
first thing his search engine spits out that sort of roughly - often
with a lot of twisted interpretation - seconds what he's saying...
Beth :)
Beth
> I'm sure it's either undefined or implementation defined, though. In
any
> case, it's best to terminate output with a newline.
"Best"? In this particular case of Sage's code, I'd say "required"...
The reason being that without the terminating newline and with it
being "implementation defined", if only _one_ implementation doesn't
interpret it correctly then it's "non-portable" (it'll produce
different results - one of which is incorrect, displaying absolutely
nothing - depending on which compiler implementation you've used)...
And Sage posted this code to an _assembly language_ forum, talking
about "portability"...with delibrate emphasis on this being "portable"
C and that the fact it'll work on every possible implementation was an
essential part of his point...as you might guess, this was all to do
with him talking about assembly's non-portability...
Hence, for him to produce a potentially non-portable piece of C++ code
actually defeats his argument here...thus, it's "required" in this
particular case or Sage's code does NOT demonstrate what he said it
was demonstrating...and actually helps to throw weight on the counter
argument that merely using C++ syntax does not automatically confer
"portability", if you go and insist on doing everything wrongly in
non-portable ways...
Sage presented this code as a perfect piece of "portability" so his
mistakes, in this context, can't be so easily excused...even if this
sort of thing is more generally excused ordinarily, because as long as
your own compiler handles it properly, that's fine (but still not role
model code...as noted, it _should_ be there :)...
Beth :)
David B. Held
news:bke52m$5l3$1...@newstree.wise.edt.ericsson.se...
> [...]
> One possibility is when one keeps calling people idiots on
> the usenet and ones service provider decides to stop
> providing the service.
That seems extremely unlikely. After all, which ISP has
the resources to monitor Usenet usage??? More likely,
The Sage realized that he wasn't going to get anywhere,
and decided to focus his energies in other crackpot
pursuits.
Dave
Attila Feher
The ISP has a good chance to catch those posts if they are forwarded in full
source to their usenet-abuse email address. Then again, The Sage might just
be outdoors for few days, abusing cats.
--
Attila aka WW
Attila Feher
> "Sage" appear...to be honest, I think the "embarass him and Hope he'll
> go away" strategy probably won't work on him, as I suspect he's doing
> this very delibrately in a "sophisicated troll" way...but, well, it's
> worth a try, at least...
Well, he did go away. And possibly it had more to do with "send his abusive
posts in full source to his NSP and ask kindly to cut them off the net"
strategy than the one you have mentioned. But of course it might only be
that he is away abusing cats and he will be back. :-(
--
Attila aka WW
Attila Feher
> P.S. When you corner him, he'll start swearing and calling you names
> and launching a personal attack...just to give you forewarning to
> expect this vulgar conduct and not to take it too personally, as he'll
> do it to _anyone_ who starts to prove that he's talking complete
> nonsense...
Well, as I have posted already: that is where he has crossed that line not
to be crossed. If he keeps posting personal insults and attacks those
personal insults and attacks will end up in his NSPs abuse-reporting mailbox
within hours. BTW after sending the first such report he has disappeared.
I just hope it is not a coincidence. :-) I am usually very very patient in
this regard. I have actually sent mail to NSPs of two people in many years
(not counting off-topic spammers). Well, The Sage was one. The other was a
guys who has accused everyone being the hand of evil or some other sickness
(Rodolfo something). He came back. Using another NSP. To end up in my
killfile when he started to post from his 3rd ISP...
> P.P.S. Actually, "C", perhaps it was unwise and not terribly clever to
> cross-post the Sage over to other groups...we wouldn't want to have
> him "spread" and "infect" other groups...he's bad enough in ours that
> we can't wish him upon anyone else...
Well, let's see. I hate the tactics I started to use but he was not only
driving people nuts, but starting to abuse people (by calling them names)
and not only the newsgroup. Let's see if he will be back. And if he will,
I guess (according to what you have said) it won't take too much for us here
to make him post things what no decent NSP will allow... Especially if they
get a hundred complaints per day.
--
Attila aka WW
Beth
mean about Sage's trolling tactics...he's clearly a complete moronic
baffoon when it comes to facts and even being able to read simple
English statements correctly...and, yet, he somehow just keeps on
getting people to respond to him in massive threads which take over
entire newsgroups for weeks...it's a persistent and insistent threat
that just refuses to go away (even if you kill-file Sage because
everyone else is somehow strangely attracted to always replying to
him, all their responses end up flooding a group with "noise")...he's
just soooo stupid, you can't believe that someone could be this
seriously in need of help and it plays on people's humanity to want to
do something - _anything_ - that might help him comprehend what most
people could manage by age 3...whether delibrate or not, it's an
amazingly effective trolling tactic he employs of complete stupidity
because, somehow, it _works_...people just keep replying and keep
feeding the troll, misguidedly thinking they may help him to "reform"
or something (it's not worth it, though...he's been like this and
hasn't learnt a thing in about a year of intermittent posting to
alt.lang.asm...he does disappear once in a while so I'm wondering if
that's when he's merely pestering some other group instead?)...
Sometimes, I'm not sure whether to consider him an absolute genius at
trolling (because he really does manage to somehow hook in on his
line, even the most rigidly "don't feed the trolls" respectable
posters, who'd ordinarily fell any other type of troll dead in their
tracks within a single post) or whether he really is just seriously
insane and completely braindead for real...but, as I pointed out to
the folks at alt.lang.asm, there's some evidence - which is "hiding in
plain sight" - that he might very well be doing this all very
delibrately and it is definitely trolling...
Look at the quote in his signature very closely:
> "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
You don't think he might possibly be so misguided and stupid as to
actually take this quote in the wrong way and believe that if he lies
sufficiently then all (American) people will start to Adore him and
admire him? In some really twisted way, all he wants is "to be Loved
and Love in return" (to probably misquote the Bard, as I'm going
totally from memory there)?
Either way, he's clearly in need of some serious, professional
help...I'm starting to agree with Randy on this...I think this could
be an actual serious mental condition or something he's got here,
perhaps...and, now, more than ever, we must stand firm by the Golden
Rule: "Do not feed the trolls"...no matter how amazingly tempting it
is to do so in the Sage's case...
Beth :)
Beth
> I'm sorry, I just couldn't sit back and watch you make a jackass of
> yourself any longer without saying anything.
Be careful of that; I'm becoming increasingly convinced (after
watching the Sage do this sort of thing on and off for about a year)
that this is _exactly_ his clever trolling strategy...he delibrately
makes a dick of himself because, sure, we _all_ can't resist...and all
feel we can't "sit back and watch him make a jackass of himself any
longer"...
When he first showed up on alt.lang.asm, I also thought exactly the
same and made loads of replies...but, really, stick firm: "Don't feed
the trolls" under _any_ circumstances when that troll's name is
"The_Sage"...now I only bother to reply to Sage just to have some
"fun" and "sport" with his complete lunancy (at the very least, it can
sometimes be highly amusing to watch, if you don't take it all that
seriously)...
Take deep breaths...keep calm...this is just the Sage's alternative
troll method of provoking a reaction...act like a total dick and
people just can't resist pointing out what a total dick you're
being...but this only serves to feed the troll...he'll next probably
try to start making legitimate claims again - which draws more people
into proper discussions - then he acts a dick, then he becomes
semi-normal again, then acts like a dick all over again...
It's using this dual "back and forth" strategy that he gains what I
call the "sophisicated troll" status...his arguments aren't
sophisicated at all...being a total moron is part of the
strategy...but this method of _trolling_ is quite clever because it
makes him the troll that people just keep on feeding over and over,
refusing to die whatever you do...he may disappear and shut up for a
month or two...but, sure enough, at least in alt.lang.asm, he starts
it all up again when he's feeling bored and he's perfected this
strategy to unparalleled levels...it really _does_ somehow just keep
on working for him...
Really, _let him_ be a jackass...I know how tempting it is to do
otherwise...but the Golden Rule really does still apply: "Do NOT feed
the trolls" under any circumstances whatsoever...
Beth :)
Attila Feher
> I think now our C++ newsgroup friends can start to appreciate what I
> mean about Sage's trolling tactics...he's clearly a complete moronic
> baffoon when it comes to facts and even being able to read simple
> English statements correctly...and, yet, he somehow just keeps on
> getting people to respond to him in massive threads which take over
> entire newsgroups for weeks...it's a persistent and insistent threat
> that just refuses to go away (even if you kill-file Sage because
> everyone else is somehow strangely attracted to always replying to
> him, all their responses end up flooding a group with "noise")...he's
Beth. There is a very good tactic against such trolls like The Sage or that
whateverMind from comp.objects. Just put all threads they start or
conteminate to be ignored. I suggest this because you seem to be very
concerned and passionate about his behaviour... but posting long analysis of
his personality is only good to keep his thread alive. Thanks God he is not
posting now for a while. Let's let this thread die of starvation.
--
Attila aka WW
Beth
> The_Sage wrote:
>
> 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.
Agreed; This was the original context in which the Sage produced this
"main" code, trying to tell us all about "portability"...hence, I
presume the cross-post was a vain attempt to get you experts in C++
matters to second this same conclusion we'd reached...
Note, look how much response the Sage can generate from one bad
two-line "Hello world" implementation...combined with the nonsense in
alt.lang.asm too, this is a monsterously large thread to deal with
such a minor thing...
I point this out because the Sage _is_ just a troll...an amazingly
effective one...if he's true to form, he'll suddenly change the topic
completely mid-thread and then manage to generate twice as much
response (replies to the idiocy he shows in his new topic and also
replies against him suddenly changing subject mid-way through, which
is tantamount to admitting defeat on the last topic...although, he
will stubbornly _refuse_ to admit that changing the subject half-way
through is an avoidance tactic in any way...but that, somehow,
"debuggers" are an important part of ISO conformance, which he'll
"prove" by talking complete bollocks for the next three weeks...before
changing the topic again...and again...and again)...and he's _very
good_ at this...even the original poster who invented the phrase
"don't feed the trolls" will find themselves eventually feeding him...
He continual varies his tactics at provoking a reaction and that his
why I refer to this as "sophisicated trolling"...by constantly
changing, no-one can keep up and you might even be tempting to think:
"oh, at last! He's beginning to see the light" so you start responding
to him again...at which point, he'll start it all over again...
He's a complete idiot about everything else but a consumate genius
when it comes to trolling...even with my outright warnings, we can
just watch...he'll _still_ be reeling people in for weeks until they
work it all out themselves that, yes, the _only_ thing that works is
to _ignore him_...completely...
Beth :)
Beth
> The_Sage wrote:
> > references or logic, I must conclude you are a total idiot.
>
> Sage, you have crossed that very line, which is not to be crossed.
Oh, no...this is actually quite restrained from "our" Sage...the final
trick in his bag is just to be so outrightly offensive that the person
he insults understandably feels they have to defend themselves or
attack back...the tradition "flame" pushed as far as he can make it
go...
There wasn't any grossly offensive swearing and cursing in this case
and that's actually amazingly restrained from Sage...perhaps he senses
"losing battle" this time and is going to hold back that honour until
he's got a better winning position - in trolling terms, his arguments
are _never_ in a winning position, as you may have guessed from his
continual moronic comments - from which to launch his trademark
assaults...
Beth :)
Beth
Nope, sorry...it's a nice thought and I only wish it could be true...
But this is how the Sage operates...he'll disappear for a while and
then reappear with some new amazingly ludicrous claim by which to
start it all off again...my guess is, he does it like this so that you
don't just get used to his tactics and then they cease to work...by
doing it in "short bursts", it's hard to get accustomed to his tricks
(we've suffered what must be at least a year - maybe more - of this
intermittently in alt.lang.asm, that the patterns _do_ eventually
become clear as crystal)...like Arnie, he'll be back (though, as
you've only met him through cross-posting, Hopefully this means he
won't be back to haunt you C++-ers again...Hopefully, this has not
given him a "taste" - like a shark with blood - for coming back to
haunt you lot (again, I understand the idea of cross-posting it
because you guys know your stuff about "main" functions to totally
prove Sage to be a complete idiot...but I still think the cross-post
was unwise because he's NOT a "virus" you want to "infect" people
with...he should be strictly "quarantined" without exception)...but I
would put money on it that he'll _definitely_ be back to haunt us
ASMites for sure)...
Beth :)
Beth
> The ISP has a good chance to catch those posts if they are forwarded
in full
> source to their usenet-abuse email address. Then again, The Sage
might just
> be outdoors for few days, abusing cats.
The second one - about abusing cats - sounds like the Sage...I think
we'll find it's definitely the "abusing cats" thing...if he was
kicking off by an ISP then I'm sure he'd just find another free Email
address somewhere and start it all again...trust me, he's NOT this
easily defeated...I only wish he was, as this isn't just a rare thing
in alt.lang.asm...he does this repeatedly and persistently and,
unfortunately, always manages to rope enough people in that it's a
serious threat to ordinary discussion...
Beth :)
Attila Feher
> Attila Feher wrote:
>> The_Sage wrote:
>>> references or logic, I must conclude you are a total idiot.
>>
>> Sage, you have crossed that very line, which is not to be crossed.
>
> Oh, no...this is actually quite restrained from "our" Sage...the final
> trick in his bag is just to be so outrightly offensive that the person
> he insults understandably feels they have to defend themselves or
> attack back...the tradition "flame" pushed as far as he can make it
> go...
Beth. Please stop bringing this thread up. Thank you.
--
Attila aka WW
Beth
I suspect the Sage would only come back using another NSP
too...although, I'd also stress that suddenly disappearing mid-thread
is completely typical Sage...perhaps, in fact, it's his way of
ensuring he doesn't get himself reported too often...at the point when
he's started boiling people's blood to want to do that, he quickly
disappears so everyone calms down again...then, of course, returns
some weeks later to do it all again...
Really, he's easily underestimated because of the total nonsense he
posts...I'm increasingly coming to the conclusion that he's actually
not really that stupid and is quite skilled at some amazingly
effective trolling tactics...in fact, the whole thing of acting like a
total moron in front of everyone I suspect is all part of the plan...I
mean, just look how many reactions his outright denial of the
semantics of the English language generates...and, also, every once in
a while, a fiendishly clever argument emerges that could in no way
come from the same "idiot" who wrote what you just read...it's all
part of the plan, I reckon...I mean, it _works_ beautifully to get
enraged reactions, doesn't it?
> > P.P.S. Actually, "C", perhaps it was unwise and not terribly
clever to
> > cross-post the Sage over to other groups...we wouldn't want to
have
> > him "spread" and "infect" other groups...he's bad enough in ours
that
> > we can't wish him upon anyone else...
>
> Well, let's see. I hate the tactics I started to use but he was not
only
> driving people nuts, but starting to abuse people (by calling them
names)
> and not only the newsgroup. Let's see if he will be back. And if
he will,
> I guess (according to what you have said) it won't take too much for
us here
> to make him post things what no decent NSP will allow... Especially
if they
> get a hundred complaints per day.
It might work...you might think me stupid but it's a whole "principle"
thing I have going...I've never and will never kill-file _anyone_
(but, sure, I'll happily _ignore_ anyone who's not making any sense :)
nor do I "grass" (that's UK slang..."inform" in everyone else's
English :) on anyone...I have my reasons for this and, yes, accept the
consequences of these decisions...so, actually, I have no idea how
effectively something like that would work on Sage...it might, indeed,
be worth a shot...
Beth :)
Beth
Well, I was actually expecting him to continue for a little bit
longer, truth be told...and, thus, the purpose of these posts was to
expose the troll immediately and encourage others to realise what he
is and ignore him straight away...to snuff the fire out before it
could even take hold...because, in a sense, the problem isn't Sage's
posts - if you see his name then you can just skip over that post -
but the fact that he tends to generate lots of replies from people you
_don't_ want to kill-file or ignore...and killing off an entire thread
because the Sage enters it isn't always possible either...other
"branches" of the thread may be good and useful...in fact, as the Sage
has a particular dislike for me naming him for what he is, if he knew
I was automatically ignoring all threads he was involved with, he'd
post up things just to "taint" every single thread so there's nothing
left for me to read...
Anyway, I'm one of those people who insists on "principle" and,
unfortunately, Freedom of Speech - regardless of how stupid or
offensive it is - and lack of censorship on the internet are things I
subscribe to whole-heartedly...so, I don't kill-file or report people
to "authorities" on those principles...posting warnings about the Sage
is, therefore, my "Freedom of Speech" way to deal with this sort of
thing...we share a common concern and I respect your decisions but,
well, we do things different ways...
But, you're right...if the Sage has stopped his nonsense this time and
everyone's now got the message plain and clear that he's just a troll
to be ignored whenever they might see his name again then my work is
done here...I'll cease from bothering everyone now...have a good time
C++-ing, until we may meet again, bon voyage...
Beth :)
P.S. Also pardon the length of my posts...I'm reknown for my
over-verbosity in the ASM groups...I've actually tried to be
restrained for you C++-ers who are not used to my little insanities :)
Attila Feher
> Well, I was actually expecting him to continue for a little bit
> longer, truth be told...and, thus, the purpose of these posts was to
Please stop bringing this thread up. Thank you.
--
Attila aka WW
Attila Feher
> I suspect the Sage would only come back using another NSP
> too...although, I'd also stress that suddenly disappearing mid-thread
Please stop bringing this thread up.
--
Attila aka WW
Karl Heinz Buchegger
Beth wrote:
>
> I think now our C++ newsgroup friends can start to appreciate what I
> mean about Sage's trolling tactics...he's clearly a complete moronic
> baffoon when it comes to facts and even being able to read simple
> English statements correctly...and, yet, he somehow just keeps on
> getting people to respond to him in massive threads which take over
> entire newsgroups for weeks...
Don't get me wrong.
It seems to work fine in your case :-)
--
Karl Heinz Buchegger
kbuc...@gascad.at
Frank Schmitt
> Andrew Koenig wrote:
> > 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.
>
> Ah, the dreaded "backwards compatibility" forever haunting you with
> design mistakes from the 1950s (okay, 1970s in C's case :)...the
> "undead" zombie that refuses to lie still in its grave and finally
> perish, like something out of Buffy the Vampire Slayer...
>
> Oh, in which case, ignore the other post I made about making it an
> error...let me guess: It can't be done because original K&R C syntax
> allowed it and, thus, forever more, it must be allowed...
No, sadly the standard committee don't even have *that* excuse - implicit
'return 0;' at the end of main was introduced with the 98 C++ standard,
AFAIK.
IMHO, the C++ standard committee did a good job overall, but this
extension is just braindead.
kind regards
frank
--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frankNO DOT SPAMschmitt AT 4sc DOT com
T.M. Sommers
> Kevin Goodsell wrote:
>
>>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.
>
> Hmmm, maybe it's because we're all assembly language posters over here
> who hate "automatic" anything and insist on everything being
> _explicitly_ defined...but, well, that seems a dodgy thing to add to
> either language...adding special exceptional behaviours...
>
> Surely, if there's lots of C / C++ coders who are not putting in the
> "return 0;" then it would be better to consider that an _error_ - to
> force them to learn to do it properly - rather than adding this
> implied behaviour to "main" as some exceptional behaviour...that cuts
> into the consistency of the language, surely, to add lots of "it's
> like this but not like that but like this if this is true but not
> this" rules into it...
I would suggest that, to the extent possible, the standards committees
wanted to make the language conform to practice. Of course, that
extent is not very much with a computer language, as compared to a
natural language, but in this case it is safe and feasible to imply
the return, lots of people omit the return, so why not allow it? I'm
sure you recall what Emerson said about consistency.
Karl Heinz Buchegger
Because it is a special case, everybody has to remember.
Adding a return 0; in every program would not have been
a problem, can be done in seconds and in half a year or
maybe a year after dropping that rule the whole issue would
be a non-issue, because main() behaves just like any other
function returning int.
T.M. Sommers
>
> Because it is a special case, everybody has to remember.
> Adding a return 0; in every program would not have been
> a problem, can be done in seconds and in half a year or
> maybe a year after dropping that rule the whole issue would
> be a non-issue, because main() behaves just like any other
> function returning int.
The only people who have to remember are the compiler writers. The
rest of us can put a return at the end of main(), and forget that it
isn't necessary.
I'm not saying that implicit return 0 is the greatest thing since
sliced bread, just that it is a defensible decision on the part of the
committee.
C
> P.P.S. Actually, "C", perhaps it was unwise and not terribly
> clever to cross-post the Sage over to other groups...we wouldn't
> want to have him "spread" and "infect" other groups...he's bad
> enough in ours that we can't wish him upon anyone else...
<sheepish> Errr ... sorry </sheepish>
[At least in my defence I can say I have resisted replying to many
of the posts here, as saying 'me too' to expert opinions adds
little more than noise.]
What I was expecting was a definate option of couple of people who
understood the C++ standard which could not be defensibly refuted,
plus a link to the standards document for future reference by
myself (as happened) -- I honestly expected TSag to ignore my post
and any responces to it as confronting them would prove him an
idiot or a troll -- the way he choose to do so points to the latter
though it does not discount the former entirely.
Normally, if the topic had been Assembly, ISO C, Java, VHDL or even
maybe Ada, I would have been able to supply the facts myself,
however C++ is outside my arena of expertese (and _very_ complex),
I had the suspicion that I was (generally) right in my original
criticisms, this (abet rather longer than I expected) thread
confirmed those suspicions.
So for those who responded with valid points and well informed
options, you provided me with exactly the information I desired in
a concise, effective and authorative way, thank you.
I should be able to respond to furture C++ based queries, of either
myself or others, by referencing the resources highlighted, so I
should no longer need to 'pester' comp.lang.c++ :-).
[After reading the FAQ and standard, I am beginning to see the C++
automatic finialisation as a _very_ good idea for a 3GL, now I just
have to figure out how to make my compiler generate efficient
assembler code to do this. I have already figured out a way using
dual stacks (data and return), implementation of which, I think,
would be permissable by the C++ standard, now to see if it can be
done with a single stack without requiring either a frame pointer
register or large amounts of tables and/or code to allow stack
unwinds.]
C
2003/9/19
PS: I now have a plan I believe will refute any posts from TSag
without generating long and offtopic threads such as this -- if
he shows up again I will test my theory out.
PPS: Beth, I think the "logical fallacy" reponce was partually
cured with this slightly sarcastic post:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=33d97ee5.0308290914.d4e4d12%40posting.google.com
(or at least it was used less frequently afterwards that reply).
PPPS: I will shutup now, as I doubt anything I could further add
to this thread would amount to anything more than a repetition of
either myself or others.
The_Sage
>Date written: Thu, 18 Sep 2003 11:35:06 +0300
>MsgID:<bkbqmg$n0$1...@newstree.wise.edt.ericsson.se>
>>The standard says you must return int, which all ISO compliant
>>compilers do, BUT IT ALSO STATES YOU CAN RETURN OTHER THINGS AS WELL.
>No, it does not. 3.6.1 Main function paragraph 2:
>"*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[]) { /* ... */ }
>"
>continuing with
>"The function main shall not be used (3.2) within a program. The linkage
>(3.5) of main is /implementation-defined/."
>For those who can read and understand (not you Rage, opps Sage) it says:
>The main function must have the return type int. However you are not
>allowed to call it so this int is for the implementation not you. The rest
>of the function signature can be whatever the implementers define *but* it
>must define the above two full signatures as valid.
>>You just proved you are illiterate.
>Nope Sage. You have just proved that not only you are clueless and
>arrogant, but it is also hopeless for you to ever change.
Wow, yet another completely illiterate idiot. Here, let me put this in simple
terms an imbecile you like could understand. From the quote you JUST GAVE...
"3.6.1 Main function paragraph 2:
It shall have a return type of type int..."
Which all ISO compilers like MS, Borland, and IBM do.
"...but otherwise..."
See that word? It means that the standard allows breathing room for other return
types other than int. Duh!
"its type is implementation-defined"
Therefore, any compiler that implements other types of main() functions other
than int main(), such as void main(), are ISO compliant. MS, Borland, and IBM
use int main() AND ALSO IMPLEMENT/DEFINE void main(), therefore they are ISO
compliant. Please get a clue before posting next time! Gawd, how stupid can you
guys get! The standard clearly state that other return types are allowed, in
addition to int!
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
>MsgID:<bkbqtq$q2$1...@newstree.wise.edt.ericsson.se>
>>>>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 proof is in my previous post.
Wrong again, since you didn't provide any quotes, you just blindly asserted it
was so. You failed to prove anything other than you have no clue what you are
talking about. Try again...but this time try to get it right, okay?
The_Sage
>Date written: Thu, 18 Sep 2003 16:56:21 -0400
>MsgID:<vmk6vmn...@news.supernews.com>
>>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.
>Don't be silly.
Don't try to dodge and evade the issue. Either you have the quotes or you do
not.
The_Sage
>Date written: 18 Sep 2003 01:18:13 GMT
>MsgID:<slrnbmi1ul....@flexal.cs.usyd.edu.au>
>>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"?
I certainly do but the real question is, do you know the meaning between
mandatory and optional? The ISO standard clearly states that you can optionally
implement other kinds of return types, therefore if you return other types other
than int, such as void, you are still ISO complaint. The int type is ISO
mandatory but the void is ISO optional, in other words.
The_Sage
>Date written: Thu, 18 Sep 2003 00:50:04 -0500
>MsgID:<bkbh5f$g5g$1...@news.astound.net>
>>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,
>Obviously, you're the one that can't read.
You are all talk and no facts. The standard states that the manufacturer can
optionally specify other types other than int, therefore *any* return type the
manufacturer specifies, such as void, is ISO compliant since the ISO standard
allows it.
The_Sage
>MsgID:<bkbrfl$16f$1...@newstree.wise.edt.ericsson.se>
>> 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.
>No.
Obviously you are illiterate, so let me put this in terms even an illiterate
idiot like you can understand...
"3.6.1 Main function paragraph 2:
It shall have a return type of type int..."
All ISO compatible compilers like MS, Borland, and IBM conform to this.
"...but otherwise..."
See that word? It means that the standard allows breathing room for other return
types other than int. Duh!
"its type is implementation-defined"
Therefore, any compiler that implements other types of main() functions other
than int main(), such as void main(), are ISO compliant. MS, Borland, and IBM
use int main() AND ALSO IMPLEMENT/DEFINE void main(), therefore they are ISO
compliant. Please get a clue before posting next time! Gawd, how stupid can you
guys get! The standard clearly state that other return types are allowed, in
addition to int!
The Sage
The_Sage
>Date written: Thu, 18 Sep 2003 11:44:25 -0400
>MsgID:<Pine.SOL.4.44.030918...@plg2.math.uwaterloo.ca>
>> A conforming implementation may provide more versions of main(), but they must
>> all have return type int.
>>It is plain and simple:
>> 1) void main() is not defined by the ISO standard but
>> 2) void main() is compliant
>I'm sorry, I just couldn't sit back and watch you make a jackass of
>yourself any longer without saying anything.
You are sorry and a jackass and an idiot. As proof...
>My god you're an idiot. What part of "they must all have return type
>int" don't you understand??
Listen up spooge for brains, all ISO compliant compilers to return int, but the
ISO standard clearly states that you can optionally implement other kinds of
return types, therefore if you return other types other than int, such as void,
you are still ISO complaint. The int type is ISO mandatory but the void is ISO
optional, in other words.
Get a clue you freaking idiot!
The_Sage
>MsgID:<vmk72t8...@news.supernews.com>
>>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.
>Wrong! *All* versions of main() must return int.
And they all do.
>It says so in plain English; you just typed it yourself!
It also says you can return other types, such as void, but obviously you can't
read plain English.
>What can vary are the *parameters* to main().
I'm waiting for one of you illiterate idiots to quote any legitimate authority
that states that all those ISO compliant compilers such as MS, IBM, and Borland
put out that, in addition to returning an int for main() also allow void, are
therefore not ISO complaint as they claim they are. Your mere opinions are not
going to change that one fact.
The_Sage
>MsgID:<bkbhb0$g5k$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.
>To introduce any more facts would be an insult to the
>numerous people who have already provided more than
>ample evidence to soundly refute your ridiculous claim.
Obviously you don't know what a fact is then. I asked you for facts and all you
can do is call people names. Are you going to bark all day little doggy, or are
you going to bite?
Noah Roberts
The standard states that the manufacturer can
> optionally specify other types other than int, therefore *any* return type the
> manufacturer specifies, such as void, is ISO compliant since the ISO standard
> allows it.
Even if that where true, C++ code that uses any other return type than
int for main is not standard compliant. Even if it is ok for a compiler
manufacturer to implement other versions of main those versions are
still vendor specific and any code that uses them is NOT compliant.
>
> The Sage
>
> =============================================================
> My Home Page : http://members.cox.net/the.sage
Your website is completely broken.
NR