can main() be overloaded??
-
hello guys...can we overload the main()?? It is just a question and i've no intentions to do so?? MY ANSWER: May be we could do it(i dont know how), but since the main() is the driver of our program so it should be punishable if someone does it:laugh:
-
hello guys...can we overload the main()?? It is just a question and i've no intentions to do so?? MY ANSWER: May be we could do it(i dont know how), but since the main() is the driver of our program so it should be punishable if someone does it:laugh:
-
hello guys...can we overload the main()?? It is just a question and i've no intentions to do so?? MY ANSWER: May be we could do it(i dont know how), but since the main() is the driver of our program so it should be punishable if someone does it:laugh:
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
-
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
-
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?
-
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
-
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
-
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
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.
-
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] -
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
intjust before the stack space formain(). 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 isint. If it's not, the return value will be bogus, not nothing.2 bugs found. > recompile ... 65534 bugs found. :doh:
-
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, butmainCRTStartup(for MS compilers and linker) that callsinit_term(true)and then callsmain(...), and -on return- callsinit_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. :doh:
-
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
intjust before the stack space formain(). 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 isint. If it's not, the return value will be bogus, not nothing.2 bugs found. > recompile ... 65534 bugs found. :doh:
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] -
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.
No, see 3.6.1.1. and 3.6.1.2 of the c++ language specification.
-
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]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 )
{
//... your code in here...
}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 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
-
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 )
{
//... your code in here...
}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 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 ofC++, anyway who cares? :-D Still, if I want to do a quick test,void main()
{
// whatever
}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] -
hello guys...can we overload the main()?? It is just a question and i've no intentions to do so?? MY ANSWER: May be we could do it(i dont know how), but since the main() is the driver of our program so it should be punishable if someone does it:laugh:
-
hello guys...can we overload the main()?? It is just a question and i've no intentions to do so?? MY ANSWER: May be we could do it(i dont know how), but since the main() is the driver of our program so it should be punishable if someone does it:laugh:
not sure about overloading, but it can be called just like a regular function. 12 Days o Christmas
-
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?
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^)
-
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()"?.