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

[Randall Hyde]

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]

HaHaHaHaHa!

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

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

 

[David B. Held]

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

 

[Guest]

On Thu, 18 Sep 2003 00:50:04 -0500, "David B. Held"

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.

 

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

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 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 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 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.

 

[Josh Lessard]

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.

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]

[ ... ]

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.

 

[Beth]

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]

In short, "the Sage" is a "sophisicated troll" that has decided to
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]

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

 

[Beth]

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]

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]

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

 

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