BOOL, TRUE, FALSE vs. bool, true, false
-
When is it appropriate to use the "special" data types defined in the Windows header files such as BOOL, TRUE, and FALSE, & when is it appropriate to use the standard C++ types like bool, true and false? I am programming in MFC, but I see both in code. Anyone who can help end some of this confusion would be appreciated. I understand types like CString, and COLORREF add functionality, but does it matter which one you use with the others I mentioned?
-
When is it appropriate to use the "special" data types defined in the Windows header files such as BOOL, TRUE, and FALSE, & when is it appropriate to use the standard C++ types like bool, true and false? I am programming in MFC, but I see both in code. Anyone who can help end some of this confusion would be appreciated. I understand types like CString, and COLORREF add functionality, but does it matter which one you use with the others I mentioned?
The SDK is all C APIs, and thus must use BOOL (which is a typedef for int, I believe). They can't use bool because that is a C++ type. MFC was developed before bool existed in C++, so it uses BOOL. New MFC features use BOOL as well, to maintain consistency. As for when to use the built-in C++ bool, I myself don't use it much. I'm just used to using BOOL (I started doing Win programming before bool existed). I will use bool's as member variables in classes, or locals in functions. But anytime you pass a flag to an API, use BOOL, because there is no implicit conversion from bool to BOOL (ie, you can't pass a bool for a parameter declared as BOOL). If you do use bool's, you'll have to pepper your code with "bSomeFlag ? TRUE : FALSE" expressions (to explicitly convert from bool to BOOL) which is fugly.
-
The SDK is all C APIs, and thus must use BOOL (which is a typedef for int, I believe). They can't use bool because that is a C++ type. MFC was developed before bool existed in C++, so it uses BOOL. New MFC features use BOOL as well, to maintain consistency. As for when to use the built-in C++ bool, I myself don't use it much. I'm just used to using BOOL (I started doing Win programming before bool existed). I will use bool's as member variables in classes, or locals in functions. But anytime you pass a flag to an API, use BOOL, because there is no implicit conversion from bool to BOOL (ie, you can't pass a bool for a parameter declared as BOOL). If you do use bool's, you'll have to pepper your code with "bSomeFlag ? TRUE : FALSE" expressions (to explicitly convert from bool to BOOL) which is fugly.
-
I do always pass directly a
boolto functions expecting aBOOL, never had any problems. Just the other direction, you must do something like this:BOOL b_old = TRUE; bool b_new = b_old!=0;*headscratch* I could've sworn VC complained if you used a bool where a BOOL (or other integral type) was expected. Ah well, my bad. :)
-
When is it appropriate to use the "special" data types defined in the Windows header files such as BOOL, TRUE, and FALSE, & when is it appropriate to use the standard C++ types like bool, true and false? I am programming in MFC, but I see both in code. Anyone who can help end some of this confusion would be appreciated. I understand types like CString, and COLORREF add functionality, but does it matter which one you use with the others I mentioned?
My approach is to use bool everywhere remotely possible and to stay as far away from MFC as much as possible :). You never know when you might have to port your code or when MS might change their minds on BOOL. I just use conditional returns like this if a BOOL is required: if ( true == bState ) { return TRUE; } else { return FALSE; } when I have to return a BOOL in an overridden function. I try to never mix BOOL and bool. Even though they serve the same purpose, they are different types and should be treated as such.
-
*headscratch* I could've sworn VC complained if you used a bool where a BOOL (or other integral type) was expected. Ah well, my bad. :)
Using VC 5, the following code: BOOL WinBool=TRUE; bool cppBool=true; WinBool = cppBool; cppBool = WinBool; produces the following: warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) I think that there are many of us C++ programers that would consider mixing types like that sloppy and we are suspicious of programmers that program like that when it is not necessary.