Sign in to follow this  
samurai_gator

Simple C++ question?

Recommended Posts

I'm getting these messages when trying to compile the following program: C:\Users\josh\Basic Functions\main.cpp|16|error: `main' must return `int'| C:\Users\josh\Basic Functions\main.cpp|16|error: return type for `main' changed to `int'| ||=== Build finished: 2 errors, 0 warnings ===| Here's the source. Any suggestions? #include <iostream> using namespace std; void R(); void R() { cout << "You are learning new stuff!\n" << "Don't stop!\n" << endl; } void main() { R(); }

Share this post


Link to post
Share on other sites
Quote:
Original post by samurai_gator
C:\Users\josh\Basic Functions\main.cpp|16|error: `main' must return `int'|
C:\Users\josh\Basic Functions\main.cpp|16|error: return type for `main' changed to `int'|

How much clearer can an error message be? You must change this line:

void main()

to this:

int main()

Share this post


Link to post
Share on other sites
A couple of tips:

// Use [ source ] tags (no spaces) to put your code in one
// of these nice little boxes :)

#include <iostream>
using namespace std;

// There's no need to declare R() here (when you learn more about declarations
// and what they're for, it'll become clear why this is).
//void R();
void R()
{
cout << "You are learning new stuff!\n" << "Don't stop!\n" << endl;
}

// Hint: look up the valid function signatures for main() in standard-
// conforming C++.
void main()
{
R();
}

Share this post


Link to post
Share on other sites
Quote:
use int main and return an int at the end of your main code block.
Provided the compiler being used complies with the standard in this respect, it's actually not necessary to include an explicit return statement in main() (in the absence of such a statement, zero will be returned).

Share this post


Link to post
Share on other sites
Another tip: std::cout doesn't require that it be fed individual lines to operator<<(). You can feed two lines at once. Also, std::endl is basically a newline followed by a call to flush() the stream, which means that any data that had been buffered will be written to the screen.

So when you wrote "...\n" << endl, you are actually writing two newlines in succession. Maybe you intended that, but if not you can omit the extra \n.

void R()
{
cout << "You are learning new stuff!\nDon't stop!" << endl;
}



If you want to separate the two lines for readability (which is a good thing), you can write to cout twice:

[void R()
{
cout << "You are learning new stuff!\n";
cout << "Don't stop!" << endl;
}

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
Quote:
use int main and return an int at the end of your main code block.
Provided the compiler being used complies with the standard in this respect, it's actually not necessary to include an explicit return statement in main() (in the absence of such a statement, zero will be returned).


That is true, but I personally believe its a good habit to get into.

Quote:
Original post by rip-off
lines for readability (which is a good thing), you can write to cout twice:


Actually still only right it once and just seperate with whitespace

cout << "Line one...\n"
<< "Line two\n";




Share this post


Link to post
Share on other sites
Quote:
Original post by Denzin
Quote:
Original post by jyk
Provided the compiler being used complies with the standard in this respect, it's actually not necessary to include an explicit return statement in main() (in the absence of such a statement, zero will be returned).
That is true, but I personally believe its a good habit to get into.
Unless you are writing a comand line tool which will be required to conform to the POSIX standard, the chance that you will ever need to return anything other than zero from main() are pretty slight.

And since program return values aren't guaranteed to be portable beyond POSIX-certified systems (i.e. Solaris and Mac OS X), I wouldn't advise you use return values for meaningful communication anyway [wink]

Share this post


Link to post
Share on other sites
Quote:
Original post by Denzin
That is true, but I personally believe its a good habit to get into.
Fair enough, but why?

Quote:
Actually still only right it once and just seperate with whitespace
cout << "Line one...\n"
<< "Line two\n";
What's wrong with repeating cout on the second line?
If you're trying to minimise on clutter and noise then why not leave out the extra streaming operator too?:
cout << "line one...\n"
"line two\n";

Share this post


Link to post
Share on other sites
Quote:
That is true, but I personally believe its a good habit to get into.
I'm also curious as to why you think returning zero explicitly at the end of main() is a good habit (I'm not saying it isn't - I'm just curious as to your reasons).

Share this post


Link to post
Share on other sites
Quote:
Original post by Denzin
just in case a compiler doesn't exactly follow standards.
Take that line of reasoning to its logical conclusion, and you will be writing software to run in 32 KB of memory, without OS support, and compiling with Visual C++ 6, "Just in case" [wink]

Share this post


Link to post
Share on other sites
Quote:
just in case a compiler doesn't exactly follow standards.
Yeah, I'd have to say that's not a very good reason. There may be cases where you have to work around a particular compiler bug or idiosyncrasy, but there's really no need to avoid using basic language features 'just in case' some compiler or other doesn't implement them correctly.

Share this post


Link to post
Share on other sites
Quote:
Original post by Denzin
just in case a compiler doesn't exactly follow standards.
If you mean the compiler might not support an implicit return then it would give you a compile-time error which you can solve by putting in a return 0 just as a one-off fix for that erroneous-error with that particular compiler. This is the usual case of coding around a compiler's idiosyncrasy once it's been identified.

If you mean that a compiler, whilst supporting an implicit return, might not be returning a success code then all bets are off anyway; in that situation there's just as much chance that explicitly returning zero won't signal a successful finish either.

I'm all for defensive coding but in a non-standards compliant world anything can happen and trying to second-guess the nature of crap compilers before you even know how and why they're crap seems arduous.

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
I'm also curious as to why you think returning zero explicitly at the end of main() is a good habit (I'm not saying it isn't - I'm just curious as to your reasons).


It's absolutely necessary to give the user the possibility to observe wether a program has ended successfully or not. Comes in very handy when you are writing a script which controls running and exiting processes for example.

Share this post


Link to post
Share on other sites
Quote:
Original post by Denzin
just in case a compiler doesn't exactly follow standards.

And just which compilers have you run across that don't follow this rule?

Quote:
Original post by lama
Quote:
Original post by jyk
I'm also curious as to why you think returning zero explicitly at the end of main() is a good habit (I'm not saying it isn't - I'm just curious as to your reasons).


It's absolutely necessary to give the user the possibility to observe wether a program has ended successfully or not. Comes in very handy when you are writing a script which controls running and exiting processes for example.


And if control reaches the end of main() without encountering a return statement, then compiler will automatically insert the return 0 for you.

Share this post


Link to post
Share on other sites
Quote:
Original post by lama
Quote:
Original post by jyk
I'm also curious as to why you think returning zero explicitly at the end of main() is a good habit (I'm not saying it isn't - I'm just curious as to your reasons).
It's absolutely necessary to give the user the possibility to observe wether a program has ended successfully or not. Comes in very handy when you are writing a script which controls running and exiting processes for example.
No, though that would be a common misconception. Standard C++ has no notion of the significance of program return values.

As I mentioned before, the only time it matters is if you are developing for a POSIX certified environment (i.e. Solaris or Mac OS X). And even there, returning zero has no meaning - if you want to signal success or failure to the enclosing environment, you need to return EXIT_SUCCESS or EXIT_FAILURE.

Share this post


Link to post
Share on other sites
@swiftcoder:

While there may not be a standard mandating it somewhere, the value from main() has plenty of meaning across Linux and Windows flavours. If you keep your return values in the range 0-255, you are pretty safe on any reasonable OS.

Its a de facto standard, even if it is not written in stone anywhere.

Share this post


Link to post
Share on other sites
Quote:
It's absolutely necessary to give the user the possibility to observe wether a program has ended successfully or not. Comes in very handy when you are writing a script which controls running and exiting processes for example.
The issue under discussion (at least as I understand it) is not 'should I return a value from main()?', but rather, 'if I'm going to return 0 no matter what, should I add the return statement myself, or let the compiler do it for me?'.

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off
@swiftcoder:
While there may not be a standard mandating it somewhere, the value from main() has plenty of meaning across Linux and Windows flavours. If you keep your return values in the range 0-255, you are pretty safe on any reasonable OS.
Sure, but what does it mean? Blindly returning a value in the range 0-255 doesn't do any good - it doesn't tell anyone anything, since any of those values could indicate any status. In particular, a value in the range 0-255 does *not* indicate success under the POSIX standard, only EXIT_SUCCESS does that (and EXIT_SUCCESS could be set to any value).

At any rate, I maintain only that In the general case, across multiple platforms, anything other than the default return of zero is a waste of time.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
At any rate, I maintain only that In the general case, across multiple platforms, anything other than the default return of zero is a waste of time.


That's an interesting theoretical argument, but seriously, how many platforms have you run into that don't support 0 for success and non-0 for failure? GNU tools such as bash and make use that convention. (And, yes, it's hard-coded and not by platform. See the manuals for the tools.) Microsoft tools such as nmake and xcopy support that convention. And between GNU and Microsoft how many platforms are left?

Share this post


Link to post
Share on other sites
Quote:
this has gotten off subject.
Just speaking as a regular forum member, I wouldn't say that this thread has drifted very far off-topic.

Threads often wander a bit (especially in For Beginners) because it often becomes necessary (or at least desirable) to clarify things or to provide additional information for the benefit of the OP and/or others who might read the thread.

As far as I can see, that's all that's happened here.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this