|
In the computer world, 1 = true and 0 = false,
but why do we return 0 to indicate it is
successful? For example,
int main()
{
// codes here
return 0; // to indicate successful
}
|
|
|
|
|
One of the reasons is because a lot of the time we want to know what went wrong. We can't have lots of different zeros, so we just let 0 be success, and have any non-zero value meaning failure. This becomes just as simple a test, except that we can get more detail if required by checking for a particular non-zero value - if the program in question returns different values for different errors.
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
There are two ways of looking at return values. One is succeeded/failed, and the boolean type is perfect for that. So true (1) indicates success, false (0) indicates failure. The other way is using a set of numbers with predefined meanings. In this case, success does not have to be 0, or 1, or 6000, or anything really. 0 is the first number, and it just happened to be assigned the meaning success (ERROR_SUCCESS).
--Mike--
Latest blog entry: *drool* (Alyson) [May 10]
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
"You have Erica on the brain" - Jon Sagara to me
|
|
|
|
|
<quote>So true (1) indicates success, false (0) indicates failure.
That's excatly why I'm confusing. In the boolean value, true is 1 and it
should indicate succeeded. But we use return 0; to indicate successful,
don't we? But of course the return type is int and it is not boolean.
I wonder can we do this to indicate succeeded?
bool main()
{
// codes here
return true;
}
|
|
|
|
|
VW_Red_Jetta wrote:
I wonder can we do this to indicate succeeded?
bool main()
{
// codes here
return true;
}
Nope. Comparing boolean return values to int return values is much like comparing apples to asparagus. As others have mentioned, there's no deep philosophical reason for the apparent contradiction in terms; merely that's the way it is technically.
If it makes you feel a bit better, you can always do this:
#include <stdlib.h><br />
<br />
int main(int argc,char **args) {<br />
<br />
<br />
<br />
return EXIT_SUCCESS;<br />
}
- Mike
|
|
|
|
|
Some questions about EXIT_SUCCESS: is it always capitalized? Can I
return exit_success? And is it deifined in stdlib.h?
I once have a trouble understanding what does it do and I'm still
having trouble with it too. Could you tell me what does
EXIT_FAILURE do? How does it return on error? Is there any alternative
to this method?
int main()
{
.
.
.
// open input and exit on error.
if(ins.fail())
{
cerr << "ERROR: cannot open";
return EXIT_FAILURE;
}
.
.
.
}
|
|
|
|
|
VW_Red_Jetta wrote:
Some questions about EXIT_SUCCESS: is it always capitalized?
Yes, all identifiers in C and C++ are case-sensitive.
VW_Red_Jetta wrote:
And is it deifined in stdlib.h?
Yes, you can check for yourself... there will probably be a line like:
<br />
#define EXIT_SUCCESS 0<br />
VW_Red_Jetta wrote:
Could you tell me what does
EXIT_FAILURE do? How does it return on error?
The return value from main() in C/C++ is passed back to the parent process or the operating system. It's a good idea to use EXIT_SUCCESS and EXIT_FAILURE, particularly for command-line apps. In Unix (dunno about Win32), the return code can be useful when your program is being run as part of a script (I won't get into the crazy world of Unix shell scripting here).
Of course, in many cases, nobody is really listening to the return value. However, it's good to get into the habit of properly returning exit codes as defined by the language or API.
VW_Red_Jetta wrote:
Is there any alternative
to this method?
When returning from main(), EXIT_SUCCESS and EXIT_FAILURE are generally the way to go. Since you're using C++, keep in mind that within your app, returning a bool or int is not the only way to signal an error has occurred. Exceptions are a powerful and versatile system for dealing with error conditions, but can be overkill for dealing with simple errors.
- Mike
|
|
|
|
|
I have seen tons of reference books doing this. They
put the braces right after the function names or class
names. For example,
instead of doing this:
class Cat
{
// codes
};
they do this:
class Cat {
// codes
};
But obviously, the first one is much clear than the
second one and not likely to make mistakes too.
What do you thinks? Especially those real world
programmers, what is your habit and why?
|
|
|
|
|
When I first started coding in C, I once spent 1.5 hours looking for an error in some example code that I was playing with. The error turned out to be a misplace } because the author was doing the :
class Foo {
// blah blah blah
}
Ever since then I have lined the braces up. Never wasted time trying to find the matching brace ever since.
Do Lipton employees get coffee breaks?
|
|
|
|
|
i would say off hand it's because it doesn't really matter.
I put the braces where ever I feel like at the given time.
hey
|
|
|
|
|
I line the braces up such as in:
class Cat
{
//blah
};
It is much easier for me to follow. The other thing I do is get a good code editor and customize the "Beautify Source" option to my liking. I then run that and it usually barfs if I have a missing brace. Which is too often.
Another thing I always do is use braces for my if statements and loops. Even if it is a simple if statement that does not require braces I use them. It makes it so much easier when I have to return to the code to figure out exactly what I was trying to put into that if statement.
|
|
|
|
|
The primary reason that you see code written like this in books is to save page space:
void foo {
// stuff
}
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Do you mean you use line up method too?
Do you do the following too?
class Cat
{
// codes
};
|
|
|
|
|
Yes, I code like this:
class Cat
{
// codes
};
I liberally use newlines and I like to organize my braces vertically.
I have seen a variety of ways that people organize their code, especially when it comes to the use of braces. I think the bottom line is what is most readable to you and your team of developers that you work with.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
If it's correct, you may want to declare a class like:
Class Cat { Cat(); ~Cat(); //some other code};
I don't think only saving page space is assumed!
|
|
|
|
|
i appreciate your code: save many lines
includeh10
|
|
|
|
|
I always do it the first way.
It takes up a few more lines, but the matching pairs are much easier to see, much neater.
Elaine ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
The tigress is here 
|
|
|
|
|
The One True Way to put the braces is the one used by Kernighan&Ritchie, and all other styles are heretic abominations. 
|
|
|
|
|
markkuk wrote:
The One True Way to put the braces is the one used by Kernighan&Ritchie, and all other styles are heretic abominations.
that's fine for C code but C++ does it properly
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
I do as :
class Cat
{
// codes
};
I think this form is better.
|
|
|
|
|
|
I have seen many discussions about this subject on this site. You may try a search to see if you can find them. Anyways, I use the first method for classes annd functions but the second for just about everything else. To me it is a matter of saving space.
John
|
|
|
|
|
I've used both styles, read code using both styles, debugged code using both styles, and as far as I'm concerned, I have no problem with either form. It's not really brace matching I have problems with -- it's parens (I once spent almost a day trying to debug a parser written in Scheme that boiled down to a missing end paren... paren matching? What's that?)
- Mike
|
|
|
|
|
The only reasonable reason for formating you code like this
class Cat {
// codes
};
is because the amount of space in published works (a.k.a books) is limited and you need to squeese the code so you can display it in less space. But formating your like this can lead to problems when debuging your code. I used this format some years back and I need to appoligise to anyone who is required to maintain it.
Trust in the code Luke. Yea right!
|
|
|
|
|
1. MFC dialog app is created
2. 2nd modeless dialog is created with extended style WS_EX_APPWINDOW, it's then shown and updated. The parent is set to null or desktop with SetParent(NULL) or SetParent(GetDesktopWindow())
3. Main dialog window is minimized, and as it is, the taskbar space for the non-modal disappears and the non-modal dialog is also minimized
4. NO, i repeat NO messages at all are sent to the non-modal dialog such as you would expect (ex. WM_SIZE message).
My Question is simple, what the heck is going on? How does one stop MFC from stealing the non-modal dialog's messages and reducing it automatically and removing it's taskbar space?
So far no one has been able to answer this 
hey
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
