>whats the reason behind using int main over void main?
Because the standard dictates that every C/C++ program must return a value to indicate its success. It also says that a program must return either 0 or EXIT_SUCCESS if the execution was successful. Declaring main() as void doesn't mean the program won't return a value -- it just means that the value it returns will probably not be 0.
And that's bad because now the operating system thinks that the execution failed. Other horrible things can happen, too. The excuse "it works for me" is not valid because it's quite possible it will eventually screw you up, and you probably don't want to spend hours looking for a bug that came of bad coding habits.
More info:
http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1044841143&id=1043284376
http://users.aber.ac.uk/auj/voidmain.shtml
John A
Vampirical Lurker
7,630 posts since Apr 2006
Reputation Points: 2,240
Solved Threads: 339
To summarize: because the standard says so.
Rashakil Fol
Super Senior Demiposter
2,658 posts since Jun 2005
Reputation Points: 1,135
Solved Threads: 177
Surprising Salem didn't comment on this.. :)
[PS: those wondering why, see his icon/avatar]
thekashyap
Practically a Posting Shark
811 posts since Feb 2007
Reputation Points: 254
Solved Threads: 75
>Surprising Salem didn't comment on this..
He probably doesn't want to explain it for the umpteenth time, like me.
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
>Always Remember The GOLDEN RULE that
That's the golden rule? Gold must be pretty worthless these days if all of the vastly superior rules were shoved aside for that one.
>when any funtion needs to return any value or recieves a value then it
>should proceed with a type of value it can recieve usually an int
Um, return and receive tend to be mutually exclusive. You should pick one when talking about return types. I'd recommend "return". "receive" is generally what one means by parameter or argument.
>ending with semicolon (;)
I think it's a a fair assumption that we all know what a semicolon is.
And of course, you didn't answer the question of why int main is preferred over void main. You just made the common mistake of pretending that main is a normal function and propagated the misconception that main's return type is the decision of the programmer. Both of which are false.
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
i'll probably get yelled at or even -repped, but, @ my university they don't even use a type for main... they just start the main as main(){ ... i know this is wrong, but, what is its effect?
Nichito
Posting Virtuoso
1,602 posts since Mar 2007
Reputation Points: 424
Solved Threads: 57
some compilers will give errors if you try that
its not the ANSI standard
jbennet
Moderator
18,523 posts since Apr 2005
Reputation Points: 1,826
Solved Threads: 601
i tried it in borland's turbo c++ and bloodshed's dev c++... none of both gave me errors... not with main, neither with void main...
Nichito
Posting Virtuoso
1,602 posts since Mar 2007
Reputation Points: 424
Solved Threads: 57
Some compilers permit nonstandard syntax when it comes to declaring main(), but that's not the same as saying int main() isn't the standard or that it's standard to use void main() or just plain main(). If you want your code to compile on as many compilers as possible then you should use int main(). Not all compilers will accept void main() or main(). All standard compliant compilers will compile int main().
Lerner
Nearly a Posting Maven
2,382 posts since Jul 2005
Reputation Points: 739
Solved Threads: 396
though not every compiler accepts the same syntax at all... or even the same libraries... for example... i've had a really bad time passing from dev to turbo c++...
Nichito
Posting Virtuoso
1,602 posts since Mar 2007
Reputation Points: 424
Solved Threads: 57
> though not every compiler accepts the same syntax at all.
Yes they will.
If you take the trouble to learn the language as defined by ANSI/ISO, then you'll have no problem writing code which will work on any ANSI/ISO compatible compiler.
The reason most people come unstuck is the first time they try to use another compiler (or port their code). At that point, they realise they've been using 'dialect C'. In other words, the 'C' which their compiler will let them get away with, not the proper 'C'.
Continually compiling the same code with multiple compilers set at their max warning levels is a good way of making sure that your code is up to spec. Running lint is a good idea as well if you want that professional touch.
Salem
Posting Sage
11,531 posts since Dec 2005
Reputation Points: 5,862
Solved Threads: 953
Also bear in mind that some old versions of turbo c++ and nearly all versions of Visual Studio do not adhere to the standard
jbennet
Moderator
18,523 posts since Apr 2005
Reputation Points: 1,826
Solved Threads: 601
Also bear in mind that some old versions of turbo c++ and nearly all versions of Visual Studio do not adhere to the standard
the c++ front-end from Edison Design Group is theonly implementation to support the complete C++ standard ISO/IEC 14882:2003. see: http://www.edg.com/index.php?location=c_lang
a good test for compiler conformance is to look at the implementation of the Dinkumware C++ library
(a completely conforming implementation of the standard C++ library ISO/IEC 14882:1998, as corrected through 2003.). as per dinkumware,
"As a general rule, you can expect reasonably complete library functionality when using Microsoft Visual C++ compilers from V7.1 onward, GCC compilers from V3.0 onward, and all compilers using the EDG front end. Only EDG compilers offer complete Standard C and C++ conformance (when used with Dinkumware libraries), and only EDG V3.5 and later supports fixed-point arithmetic (TR18037)."
http://www.dinkumware.com/manuals/
current versions of the microsoft c++ compiler use libraries from dinkumware; gcc libstdc++ implementations from version 3.4.0 are also fairly conformant. the recently released Turbo C++ 2006 (sep 2006) includes the Dinkumware C++ libraries and my guess is that the conformance would be reasonable.
vijayan121
Posting Virtuoso
1,606 posts since Dec 2006
Reputation Points: 1,159
Solved Threads: 287
>I believe that ANSI C actually standardized the fact that a function with
>no return type specified will be taken as int.
The implicit int rule was removed in the most recent standard. It was a poor practice before, and it's illegal now.
>I believe thats the reason most compilers let u have it your way with that..
Sort of. The latest standard isn't widely implemented yet, so most compilers will be using the previous standard to compile. In that standard, implicit int is still allowed. But the community doesn't recommend it for various good reasons.
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
thank you very much for the explanation... i've been asking this to all of my teachers and none of them has had a convincing answer...
thnks :)
Nichito
Posting Virtuoso
1,602 posts since Mar 2007
Reputation Points: 424
Solved Threads: 57