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

[Randall Hyde]

Actually you are right, I have no idea why your compiler compiles
syntatically incorrect code. My best guess is that you are exploiting a
bug in the parser, but yes - I don't actually know as I don't even know
what compiler you are using.

How do you know he's even telling the truth about what his compiler
does? How do you know he's telling the truth about even bothering to try
and compile the code. He has a history of posting all kinds of "facts"
without actually trying things out and then arguing that they're correct
when they obviously are not. Sooner or later he changes the subject
or lets the argument quietly drop (notice how he doesn't say much about
that missing semicolon anymore?).

My best guess is that his compiler *does* return errors on syntactically
incorrect code (i.e., a missing semicolon), but he's not going to admit
he was wrong, even on something as innocent as a typographical error.
Cheers,
Randy Hyde

 

[Attila Feher]

Quotes then please.

I gace you the quote. Even explained it to you. Care to read it.

 

[Attila Feher]

Quotes then please.

Did you see Herb Sutter, the C++ community liaison of Microsoft here in this
thread letting you know that void main is not standard, and their compiler
accept is only as an extension? Or you choose not to see that already two
language gurus have told you you are wrong?

 

[Attila Feher]

So what? No one made the claim that it could. Get with the program
please.

And you still haven't proved anything. I quoted where ISO standard
says it is okay to use "void main()" but even if you want to blindly
and ignorantly deny that fact, then explain why MS, Borland, and IBM
all agree with my interpretation of the ISO standard?

They don't. Herb Sutter from MS, who is "the spokesman for Microsoft C++"
just showed you they don't.

And the others don't either. They have void main as a non-standard
extension. Which is non-standard, because the standard does not allow it.
But the compiler can still be conforming if it remind you that you are not
writing conforming code.
[The Rage of Sage gibberish SNIPped]

 

[Gavin Deane]

Obviously english isn't your first language. The ISO standard uses the "but" in
a proper form, as in "You are required to attend but you are allowed to bring
someone else if you like".


It is one sentence with one subject. You haven't been told this but now you
have. It is elementary english grammer.

Obviously English isn't your first language. The word is "grammar". It
is elementary English spelling.

 

[Attila Feher]

Obviously English isn't your first language. The word is "grammar". It
is elementary English spelling.

He does not even understand English. How do you think he could spell. He
has no idea that otherwise might also mean "from any other respect, but the
ones mentioned so far". Poor guy.

 

[Attila Feher]

By definition, truth is what people believe is (or accept as) a fact,
not what actually is a fact.

By definition the truth in technical matters is *fact*.

You stand corrected.

Not really. It is you The Sage, who stands corrected at least 40 times in
this thread.

I never said otherwise. Obviously you haven't been paying attention
to anything that was said over the last 10 posts.

Might it be that all your posts are the same baseless claims and personal
insults so if you have read one you have read it all?

My claim is, and
always has been, int has to be one of the return types included in an
ISO compliant C++ compiler, but viod is optionally allowed as return
type, if the manufacturer so chooses to do so.

No. You have said that void main is ISO standard just like int main. Which
is completely wrong. But I see you have read Herb's article and fast
changed you tactics.

Done. I provided the quotes from the ISO standard...can't you read?

No. I provided the quotes in this thread first time and the quote says:
main must return int. The rest of its type is implementation defined.

Wrong.

Not wrong. If it accepts both the same way, the compiler did violate the
standard and it is not conforming. It is ought to issue diagnostics on the
void main. Futhermore we were not discussing *compiler* compliance but
*code* compliance. And a code containing a void main is not standard
conforming C++ code.

The part that says, " "It shall have a return type of type int..."

Which means exactly that. It shall have the return type of int. Not void,
not double, not std::string. Furthermore have you had any experience with
technical documents you would know that in them shall means what must means
in life.

Can't you read or pay attention to the last 10 posts?

What for? Did you write anything else then your usual mindless ranting?

Why should I waste my time with your ignorance?

The only ignorant here is you.

You aren't going to be reasonable
or honor us with an intelligent dialog.

Ahh. I am starting to see you are talking about yourself.

Heck, I gave the paragraph
and sub-heading where the standard states what main() can return or
not, and you either cannot understand simple english sentences, don't
want to understand simple english sentences, or you pretend to not
understand simple english sentences.

Yes. The Sage is talking to himself on the internet.

Case in point: I asked for facts
and all you gave in your rebuttal just now was your opinion. No
logic. No quotes from the standard. No links to legitimate
references.

Yes. Definitely. The Sage has finally gone mad and is talking to himself.

Just you playing ignorant of all that preceded your post.
Go back and read all those posts you obviously didn't look at, then
come back and see if you can hold an intelligent, fact-filled,
standard quoting post, because apparently you don't want to be
serious about this issue, which makes you a joke.

Yes. Definitely. The Sage has finally gone mad and is talking to himself.
It must be it. He is the only ignorant person in this thread who does not
read posts as rarely reacts to any of its content, he can only copy quotes
of the standard I posted here, he is the one who gives an opinion and tries
to sell it as a fact - and he is the one who cannot make an intelligent
conversation. He is talking to himself. This must be the first time in the
history of the USENET that a troll has gone bananas and talks to himself in
his posts...

I do not feel obliged to believe that the same God who has endowed us with
sense, reason, and intellect has intended us to forgo their use. [Galileo
Galilei]

One gets the feeling that trolls also existed back then. Only they worked
for the inquisition.

 

[Attila Feher]

Herb Sutter wrote:
[SNIP]

Yes, of course assuming it is otherwise conforming. Put another way:
Accepting "void main()" does not in itself make a compiler
nonconforming. That is a conforming extension, as long as the
compiler still emits a warning.
Sure.


Right, such a program is not a standard C++ program. It makes use of a
common but still nonstandard C++ extension.

OK. Case #29847293 closed. This was one (if not the main) of The Sage's
ideas here that a program declaring main with void return type is standard
conforming. Now I hope it is fully clarified that it is not.

I wonder if anyone can convince him about the fact that in C++ } is not a
substitue for ;} and so forth. I don't think and I don't think it is
important. It was important to clarify (in case any newbies read this
thread) that void main is a (not necessarily portable) language extension,
which makes the code to cease to be standard C++ code. Furthermore it makes
it real fun to use that program in a makefile. You can make bets what will
be in AX the next time. Will it stop the process or let it go?

 

[Attila Feher]

analogy would be Borland's __property extension. No
conforming C++ compiler could be expected to compile
this code:

#define __property

class foo
{
__property int bar;
};

;-) I had to do such ugliness many years back.

 

[Attila Feher]

Good comeback!

It is, indeed. Since compilers will not compile your code, due to a missing
semicolon.

 

[Alexander Terekhov]

Attila Feher wrote:
[...]

important. It was important to clarify (in case any newbies read this
thread) that void main is a (not necessarily portable) language extension,
which makes the code to cease to be standard C++ code.

And that it ought to be standard (instead of silent "return 0" hack).

This "is" the FUTURE:

<whatever> main(/*... no changes here ...*/)
throw(std::thread_cancel_request,
std::thread_exit_request,
std:rogram_exit_request)

and <whatever> can be void, of course.

regards,
alexander. <in "nostradamus modus", sort of>

 

[James Lothian]

It says the compile was successful.

Cut and paste the compiler's output, as I did.

 

[Attila Feher]

Attila Feher wrote:
[...]

important. It was important to clarify (in case any newbies read
this thread) that void main is a (not necessarily portable) language
extension, which makes the code to cease to be standard C++ code.

And that it ought to be standard (instead of silent "return 0" hack).

This "is" the FUTURE:

<whatever> main(/*... no changes here ...*/)
throw(std::thread_cancel_request,
std::thread_exit_request,
std:rogram_exit_request)

and <whatever> can be void, of course.

Sure. And then you call std::exit(void); ... I don't think so.

 

[Alexander Terekhov]

Attila Feher wrote:
[...]

important. It was important to clarify (in case any newbies read
this thread) that void main is a (not necessarily portable) language
extension, which makes the code to cease to be standard C++ code.

And that it ought to be standard (instead of silent "return 0" hack).

This "is" the FUTURE:

<whatever> main(/*... no changes here ...*/)
throw(std::thread_cancel_request,
std::thread_exit_request,
std:rogram_exit_request)

and <whatever> can be void, of course.

Sure. And then you call std::exit(void); ... I don't think so.

And then you "throw std:rogram_exit_request(EXIT_FAILURE);" or do
something like that (e.g. use "void std:rogram_exit(int status) {
throw std:rogram_exit_request(status); }") for any "exceptional"
exits (something like std::set_exit_status() that would be usefull
for overriding program exit status in the destructors of objects of
static storage duration aside for a moment), of course. Think, WW.

regards,
alexander.

 

[Attila Feher]

And then you "throw std:rogram_exit_request(EXIT_FAILURE);" or do
something like that (e.g. use "void std:rogram_exit(int status) {
throw std:rogram_exit_request(status); }") for any "exceptional"
exits (something like std::set_exit_status() that would be usefull
for overriding program exit status in the destructors of objects of
static storage duration aside for a moment), of course. Think, WW.

I did. How about that. A function can be exited without throwing an
exception. A function with void return type can be exited without returning
anything. So was it failure or success?

 

[Buster]

Good comeback!

If I wanted comeback, I'd have wiped it off your mother's chin.

 

[Alexander Terekhov]

Attila Feher wrote:
[...]

I did. How about that. A function can be exited without throwing an
exception. A function with void return type can be exited without returning
anything. So was it failure or success?

Return value (of whatever type) or lack thereof (think of thread cancel)
is meant to be meaningful ONLY for joining thread(s) within program, if
any. There shall be no difference with respect to main() and any other
thread routine (just like there IS no difference with respect to initial
["main"] thread and any other thread TODAY). As for your question about
program exit status, well, of course, it was success... unless program
exit status was overridden with something else (and this can be done
either before or after return; during program/process termination).

regards,
alexander.

 

[Attila Feher]

Attila Feher wrote:
[...]

I did. How about that. A function can be exited without throwing an
exception. A function with void return type can be exited without
returning anything. So was it failure or success?

Return value (of whatever type) or lack thereof (think of thread
cancel) is meant to be meaningful ONLY for joining thread(s) within
program, if any.

I do not recall the C++ Standard to contain anything about threads.

There shall be no difference with respect to main()
and any other thread routine (just like there IS no difference with
respect to initial ["main"] thread and any other thread TODAY). As
for your question about program exit status, well, of course, it was
success... unless program exit status was overridden with something
else (and this can be done either before or after return; during
program/process termination).

Well, it might make sense, but the idea has to be studied further. For
example it is absolutely possible today that for an environment where it
makes sense main would return an std::string - as an extension. But I doubt
to see how could that be implemented or required to be implemented on every
platform. Since as you have said main could return anything.

Also I find it wrong to mix the main entry point of a process (the main
function) with entry points of threads. There is one entry point of a
program, and that is its main function. In case of successful completion
there is one exit point of the program: in the same function. While I am
ready to believe that (if we play with threads) it can be another thread
which is the last one - not the one created at process startup (if that
thread was cancelled but others remained) - even in case of success. But
that seems to complicate the issue if exit possibly status beyond
recognition and I also fail to see what benefits would it give.

 

[Attila Feher]

It says the compile was successful.

"the compile was successful" Where was this compiler created? Verbally
impaired-land?

 

[Attila Feher]

If I wanted comeback, I'd have wiped it off your mother's chin.

Now that *was* unprofessional.