|
Nope, you can't overload main(), at least not in standard C++. You might be able to in C (or rather assign some other object to main by tricking the linker) though.
Cheers,
Ash
|
|
|
|
|
overloaded Name wrote: hello guys...can we overload the main()??
Meaning what? Are you wanting to change the name of your program's entry point? Or are you referring to the many faces of main:
void main( void )
int main( void )
void main( int argc )
int main( int argc )
void main( int argc, char *argv[] )
int main( int argc, char *argv[] )
void main( int argc, char *argv[], char *env[] )
int main( int argc, char *argv[], char *env[] )
"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
|
|
|
|
|
main always should have a return type of int. Even Microsoft compilers know that if you tell them to disable MS extensions to the language.
|
|
|
|
|
Aescleal wrote: main always should have a return type of int.
It all depends on what you're doing. I seldom use anything other than void, and for good reason.
"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
|
|
|
|
|
Well personally I usually use a C++ compiler to compile C++, but your milage may vary.
Just out of interest what do you think happens if you write:
int main()
{
}
What's returned to the OS? Do you think it's anything different to what happens if you write:
void main()
{
}
and compile with /Ze on Microsoft's compilers?
|
|
|
|
|
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
|
|
|
|
|
Sounds like an interesting concept - not using code that's marginally shorter, standard and portable. At least it'll help confuse future generations of programmers.
|
|
|
|
|
I don't agree.
While I see the point of returning a value of the OS, I personally don't like 'default 0-return value' for code intended to return nothing.
Moreover, the implicit 'return 0;' statement in the following code is confusing too (at least IMHO).
int main()
{
}
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: While I see the point of returning a value of the OS, I personally don't like 'default 0-return value' for code intended to return nothing.
The ponit is that, whatever you like it or not, a process invoked by the OS HAVE TO return an int value back to it. That's how all the kernels are designed.
The OS left the space for an int just before the stack space for main(). Just like C does for whatever function call.
If you declare main as void, you simply tell your program to don't care about the stack under it. That -in fact- doesn't mean "return nothing": it just return to the OS a random value.
The OS is not compiled by you and doesn't link statically your main, so it cannot know what the type it has. It assume it is int. If it's not, the return value will be bogus, not nothing.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I understand that.
However, from my point of view (as developer), sometimes I simply don't care about returning a meaningful value to the OS. I simply need the OS executing the piece of code, no more, no less.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Why is it confusing? It's only been around since 1989 (with the first C standard). If it really offends you do something like:
void my_main( int argc, char **argv )
{
}
and add a standard and portable main to a library:
int main( int argc, char **argv )
{
my_main( argc, argv );
}
boom boom, you've got what you want (effectively a void entry point to your app) and the great Gods of the C++ standard are appeased as well.
And once you start doing that you can go a bit further...
int main( int argc, char **argv )
try
{
std::vector<std::string> args;
std::copy( argv, argv + argc, std::back_inserter( args ) );
my_main( args );
}
catch( std::exception &e )
{
std::cout << "Something went wrong: " << e.what() << std::endl;
}
catch( ... )
{
std::cout << "Something went wrong, no idea what!" << std::endl;
}
You can start kicking all the boiler plate guff you normally have to do in main away from the meat of your app (creating and wiring you application objects up). Anyway, that last bit is a bit of a digression - the point is don't fight the standard, it'll win in the end - do what a good programmer does with a chuffy API and abstract it, hide it or adapt it.
Cheers,
Ash
|
|
|
|
|
Implicit return 0; statement is confusing, no matter if it is around since then (I would prefer the compiler complaining about the missing return statement).
I know my arguments go against the Good Lord of C++, anyway who cares? 
Still, if I want to do a quick test,
void main()
{
}
is my favourite paradigm.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
A main function returning void is 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 the return statement; in C, you can't omit it, just return 0.) A compiler that allows a main returning void breaks 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. 
"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.
|
|
|
|
|
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.
|
|
|
|
|
I'm not misunderstanding anything. Of course it returns an int it is simply garbage therefore useless.
|
|
|
|
|
yes...i was refering to change the program's entry point. I was just asking the question and have no intensions to even experiance it.
|
|
|
|
|
Not properly in a "portable" way. But the most of the linkers (including microsoft) allow to specify a different "entry point function".
But I suggest to be very careful about that.
The actual entry point (for the OS) for a C++ program is not main, but mainCRTStartup (for MS compilers and linker) that calls init_term(true) and then calls main(...), and -on return- calls init_term(false);
They are internal C-Runtime library function necessary to initialize all the global and static variables you may have in your program that require a call to a constructor.
Skipping those functions means you have no chance to initialize global and static objects, and handle their destruction at program termination.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
