stupid question.. what's "return 0"?
return exits from a function and makes the funciton give a value back to whatever called it.
For example, in:
Now Sum will have 5, becase that is what add passed back
For example, in:
int Add(int Num1, int Num2){ return Num1 + Num2;}int Sum;Sum = Add(3, 2);Now Sum will have 5, becase that is what add passed back
return 0 is generally, but not always, an error, or a false condition. Take for example this code:
The function can be used in if conditionals.
int isBaseballExciting(){ return 0;}The function can be used in if conditionals.
if (isBaseballExciting()){ WatchTheGame();}else{ TurnOnAquaTeenHungerForceDVD();}
Unforunately, sometimes return 0 also indicates that there is no problem, such as with the main function. Almost as if the query was "IsThereAProblem()" or "DidTheFunctionFail()" so that "return 0" indicates that there was no problem.
Quote:Original post by Inmate2993
return 0 is generally, but not always, an error, or a false condition.
Actually, C and C++ idiom is to consider return 0 a successful completion. This stems from Unix command line utility idiom, where a program that terminates successful generates no output to the terminal.
Your example is rooted in "old" C idiom, and definitely not C++ idiom because of the presence of the bool type in C++ and C99. In fact, your example is dependent, in C++ and C99, on the promotion of zero integral values to false (and non-zero values to true).
Quote:Original post by Oluseyi
Your example is rooted in "old" C idiom, and definitely not C++ idiom because of the presence of the bool type in C++ and C99. In fact, your example is dependent, in C++ and C99, on the promotion of zero integral values to false (and non-zero values to true).
So you would recommend returning 0 for success? I find that a bit misleading, and have been using return 1 for that very reason, that it makes more sense that way. Care to explain to me exactly why we shouldn't rely on something that is in fact in the standards? (I do believe it is standard that 0 gets evaluated as false, and anything else as true?) Or, on the other hand, correct me if I am direly wrong, as I would hate to be doing something for reasons that are not in fact good ones.
You are partially right. Many functions in the STL return 0 upon success. And so do many in other APIs and Libraries. However, when used in an if statement, 1 DOES evaluate to true and 0 and under to false. So this:
would be
However,
would be true.
Back to the normal topic:
well, returns something. main() returns 0, meaning success. Lets say we want to multiply something, but using a function. It would be:
-DBZ-
int a = 1;int b = 0;int c = 3;bool all = a && b && c;would be
all = false;However,
bool all = a || b || c;would be true.
Back to the normal topic:
returnwell, returns something. main() returns 0, meaning success. Lets say we want to multiply something, but using a function. It would be:
int Multiply(int foo, int bar) // its an int because it will return an int{ return foo * bar; // it will return foo times bar}int main() // main{ int foobar = Multiply(13, 13); // foobar would get the return // of multiply, or 13 * 13, // or 169 return 0; // success}-DBZ-
If you only need two discretee codes then that's the natural thing to do, but then you should really use a boolean type and named true/false constants too.
However using 0 as a sign of success has a few advantages. For instance you often want multiple error codes but only one error code, in which case 0 is the natural choice since it can easily be distinguished from the rest. This is how the return code from main works.
When you both need multiple positive and negative return codes it's common to return negative values for errors and positive ones otherwise (including zero), again this is because it's so easy to separate the two sets and negative "success" codes would've been unintuitive. This is how Microsoft's HRESULTS work for instance.
Additionally some libraries return string constants containing the error messages themselves instead of integer codes in which case 0 (NULL) is the only real choice left.
However using 0 as a sign of success has a few advantages. For instance you often want multiple error codes but only one error code, in which case 0 is the natural choice since it can easily be distinguished from the rest. This is how the return code from main works.
When you both need multiple positive and negative return codes it's common to return negative values for errors and positive ones otherwise (including zero), again this is because it's so easy to separate the two sets and negative "success" codes would've been unintuitive. This is how Microsoft's HRESULTS work for instance.
Additionally some libraries return string constants containing the error messages themselves instead of integer codes in which case 0 (NULL) is the only real choice left.
Quote:Original post by SirLuthor
So you would recommend returning 0 for success?
I recommend choosing one convention and sticking with it. Personally, I use a non-zero value to indicate an error since there can be more than one type of error yet there is typically only one type of success! An alternative strategy is the following:
#define SUCCESS 1
#define FAIL_DISK 2
#define FAIL_IO 3
...
#define SUCCEEDED(x) ((x) == SUCCESS)
#define FAILED(x) ((x) != SUCCESS)
...
if (SUCCEEDED(DoSomething())) { return 0; }
In my opinion, the lack of good error handling is one of the most difficult issues to overcome in C. I wish the language itself had better support for them!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
