|
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
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
|
|
|
|
|
Is it possible to customize the windows task bar (not the system tray) items so that you can change the text that appears next to the task bar icon for an application? Also could you replace the text that appears next to the icon by a bitmap.
That is instead of having "<mfc icon=""> MyApp.exe" appear in the windows task bar, you could have "<mfc icon=""> MyApplication" or "<mfc icon=""> 'A Bitmap'".
There seem to be a lot of articles on the system tray, but I havent seen any on the task bar.
Many thanks
3green
|
|
|
|
|
AFAIK Windows displays the Main Window title and it's icon on the task bar.
The title can be set with SetWindowText
in MFC, it's taken from the resource string IDR_MAINFRAME and optionally the current document name is added. The icon is the IDR_MAINFRAME icon resource.
Helped?
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|