can main() be overloaded??
-
Aescleal wrote:
What's returned to the OS?
What you are failing to realize is that I don't care what's returned to the OS (i.e., the invoker), if anything. To put it another way, if all I'm doing is some proof-of-concept code, having
main()return and accept nothing is perfectly valid."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
A
mainfunction returningvoidis invalid in both C and C++, end of story, no matter that you care about what your program returns or not. (In C++, if you don't, just omit thereturnstatement; in C, you can't omit it, justreturn 0.) A compiler that allows amainreturningvoidbreaks portability to other compilers (GCC, Intel). This is clearly stated in ISO's C++ specification (section 3.6.1; also answering the original poster's question):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.
See also: C++ FAQ Lite [29.3] Should I use void main() or int main()? and Stroustrup: Can I write "void main()"?.
-
A
mainfunction returningvoidis invalid in both C and C++, end of story, no matter that you care about what your program returns or not. (In C++, if you don't, just omit thereturnstatement; in C, you can't omit it, justreturn 0.) A compiler that allows amainreturningvoidbreaks portability to other compilers (GCC, Intel). This is clearly stated in ISO's C++ specification (section 3.6.1; also answering the original poster's question):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.
See also: C++ FAQ Lite [29.3] Should I use void main() or int main()? and Stroustrup: Can I write "void main()"?.
DrFrankenstein90 wrote:
...no matter that you care about what your program returns or not.
You're right. How silly of me. What could I have possibly been thinking. :rolleyes:
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
-
If you define it as void nothing is returned. If you define it as int and don't "return" or "exit(something)" then it's going to be God knows what and totally meaningless. 8^)
False. The standard explicitly says that if you omit the return statement, main must return 0. Older compiler didn't do that, bat that was their fault. void main() is not C++. It is a Ms extension, that have been adopted also by very few other compiler designed for windows environment. whither you define main (int or void) the system cannot know (it is not statically linked to your program) and always expect an int to be returned. if you return void your main function, simply doesn't write any value in the bottom of the stack, that is left as the OS created it (i.e. with garbage inside).
2 bugs found. > recompile ... 65534 bugs found. :doh:
-
No, see 3.6.1.1. and 3.6.1.2 of the c++ language specification.
Irrelevant. The question is another: can the OS invoke something different than main? That does not depend on C++ specs, but on how the linker is instructed. What about
WinMain?!?2 bugs found. > recompile ... 65534 bugs found. :doh:
-
False. The standard explicitly says that if you omit the return statement, main must return 0. Older compiler didn't do that, bat that was their fault. void main() is not C++. It is a Ms extension, that have been adopted also by very few other compiler designed for windows environment. whither you define main (int or void) the system cannot know (it is not statically linked to your program) and always expect an int to be returned. if you return void your main function, simply doesn't write any value in the bottom of the stack, that is left as the OS created it (i.e. with garbage inside).
2 bugs found. > recompile ... 65534 bugs found. :doh:
Well I didn't go into as detailed a explanation but the bottom line is the same... garbage for a return value.
-
Irrelevant. The question is another: can the OS invoke something different than main? That does not depend on C++ specs, but on how the linker is instructed. What about
WinMain?!?2 bugs found. > recompile ... 65534 bugs found. :doh:
No. The question was: "Can main() be overloaded?". The answer is no. However, the standard does not enforce the existence of "main" - it leaves it up to the implementation how the entry point of a program is defined. But if the entry point is main, "it shall not be overloaded"...
-
not sure about overloading, but it can be called just like a regular function. 12 Days o Christmas
...not in a "well formed c++ program" according to c++ standard.
-
No. The question was: "Can main() be overloaded?". The answer is no. However, the standard does not enforce the existence of "main" - it leaves it up to the implementation how the entry point of a program is defined. But if the entry point is main, "it shall not be overloaded"...
Please read all the post: just four line up yours, the OP clarified we where all misleading his originally malposed question!
2 bugs found. > recompile ... 65534 bugs found. :doh:
-
Well I didn't go into as detailed a explanation but the bottom line is the same... garbage for a return value.
Sounds like you're misunderstanding Emilio. In case you missed the earlier posts... main() is special. - you can't call it - it always returns an integer - if there isn't an explicit return statement the compiler inserts an effective "return 0;" on that control path So the return value is never "garbage" it's always well defined - either by the programmer or the standard.
-
Sounds like you're misunderstanding Emilio. In case you missed the earlier posts... main() is special. - you can't call it - it always returns an integer - if there isn't an explicit return statement the compiler inserts an effective "return 0;" on that control path So the return value is never "garbage" it's always well defined - either by the programmer or the standard.
I'm not misunderstanding anything. Of course it returns an int it is simply garbage therefore useless.