Hi guys,
In Win32 (Visual Studio) is bool exactly the same as BOOL ?
What exactly is BOOL ?
typedef int BOOL
or maybe
#define BOOL int
or something else ?
I'd rather use bool but want to make sure it's really the same.
Thank you.
Win32 BOOL and bool ?
The Win32 API is a C library. C does not have a boolean type. Therefore, Win32 has defined BOOL as being an integer having zero and nonzero for false and true respectively.
EDIT:
See Win32 Data Types.
EDIT:
See Win32 Data Types.
bool is a C++ type, BOOL is a win32 typedef for int, but the underlying type should not matter (hence why its typedeffed).
If you're writing a C++ app, use bool, if you're interfacing with Win32, use BOOL.
Note that sometimes the use of BOOL in the Windows API is a lie and is not actually a boolean. For the GetMessage() function, 0 indicates WM_QUIT, non-zero indicates a non-WM_QUIT message except for -1 which means an error.
Note that sometimes the use of BOOL in the Windows API is a lie and is not actually a boolean. For the GetMessage() function, 0 indicates WM_QUIT, non-zero indicates a non-WM_QUIT message except for -1 which means an error.
WAT?
Are they crazy? (Rhetorical question).
I actually had to double-check that info on MSDN, I thought you were trolling. But you're not. And that frightens me to death.
Note that sometimes the use of BOOL in the Windows API is a lie and is not actually a boolean. For the GetMessage() function, 0 indicates WM_QUIT, non-zero indicates a non-WM_QUIT message except for -1 which means an error.
Are they crazy? (Rhetorical question).
I actually had to double-check that info on MSDN, I thought you were trolling. But you're not. And that frightens me to death.
There's probably a legacy reason for that - maybe something to do with the original GetMessage in an earlier version of Windows returning a strict BOOL, but when they moved it to 32-bit (or something else, I don't know) they needed to return another value but couldn't change the function signature for compatibility reasons. Windows is full of stuff like that - check out Raymond Chen's blog for more info.
In that case, they have made a function with a completely different interface that actually breaks backward compatibility. They could as well have renamed the return type at the same time or made a second function.
In that case, they have made a function with a completely different interface that actually breaks backward compatibility. They could as well have renamed the return type at the same time or made a second function.
Ahh, here we go: http://blogs.msdn.com/b/oldnewthing/archive/2013/03/22/10404367.aspx
We can infer from that (and the "somebody said" linked post) that the addition of -1 as a return code happened during the changeover from Windows 3.0 and 3.1 when parameter validation was added to these functions. As for the alternatives you suggest in your second sentence, I obviously don't know the reason why they didn't, but I'm going to assume that there was such a reason.
When it comes to the Windows API, you don't need to make stuff up. For that matter I couldn't make some of this stuff up if I tried. Another true but unbelievable detail about BOOL: there's not just one typedef or two typedefs for boolean types in the API, but three of them (that I know about): BOOL, BOOLEAN and VARIANT_BOOL. They are respectively, 4 bytes, 1 byte and 2 bytes. VARIANT_BOOL is especially interesting because it doesn't use non-zero for true but specifically 0xffff (-1 as a short). Also BOOL and VARIANT_BOOL are signed, and BOOLEAN is unsigned. BOOLEAN is a fun one because you can do accidental integer conversions that don't mean what you think they do. bool(my_int) means true if my_int is non-zero. BOOLEAN(my_int) means take the least significant byte (in other words 256 would look like false).I actually had to double-check that info on MSDN, I thought you were trolling. But you're not. And that frightens me to death.
BOOL vs. VARIANT_BOOL vs. BOOLEAN vs. bool
Again, there's a reason for everything. I'm not necessarily saying that all of them are good reasons, just that they are reasons.
i guess that this is a characteristic of an API that's developed over 30-odd years. We see the same in legacy OpenGL where there are often 5 different ways of doing the same thing, and not consistently specified.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
