Reputation: 2193
When should BOOL and bool be used in C++ and why?
I think using bool is cleaner and more portable because it's a built-in type. But BOOL is unavoidable when you interactive with legacy code/C code, or doing inter-op from .NET with C code/Windows API.
So my policy is: Use bool inside C++. Use BOOL when talk to outer world, e.g., export function in windows DLL.
Is there a definitive explanation of when to use one over the other?
Upvotes: 23
Views: 8139
Reputation: 25925
If you wish to use a function written in C++ (for example embedded in DLL library) in managed program (for example in C#), you have to use BOOL. If you return bool, the result will always be true - this is known bug for a long time and apparently not yet resolved (VS 2010, .NET Framework 4).
Best regards -- Spook.
Upvotes: 1
Reputation: 7
I think of "true"/"TRUE" and "false"/"FALSE" as syntactic sugar, a solution to a problem that never existed. I've always thought it easier to both use and read "1" and "0".
When you think about flags in registers being on or off, do you think in 1s and 0s or trues and falses? What happens if you want to store several flags in a single variable? 1s and 0s are universal.
I think the word "false" is too long for its own good. When I see a "0", it stands out in my mind like a red stop sign. Stop signs are red because the color red gets people's attention. Reading the word "false" is like seeing a green stop sign.
So, to hell with bool and BOOL. I default to int.
...but, really, getting boolean flags right is the least worry in a language with as many ways to make a mistake as C++.
Upvotes: -2
Reputation: 58352
Matthew Wilson discusses BOOL
, bool
, and similar in section 13.4.2 of Imperfect C++. Mixing the two can be problematic, since they generally have different sizes (and so pointers and references aren't interchangeable), and since bool
isn't guaranteed to have any particular size. Trying to use typedefs or conditional compilating to smooth over the differences between BOOL
and bool
or trying to allow for a single Boolean type to work in both C and C++ is even worse:
#if defined(__cplusplus) || \
defined(bool) /* for C compilation with C99 bool (macro) */
typedef bool bool_t;
#else
typedef BOOL bool_t;
#endif /* __cplusplus */
This approach means that a function's return type can differ depending on which language calls it; Wilson explains that he's seen more than one bug in his own code and others' that results from this. He concludes:
The solution to this imperfection is, as it so often is, abstinence. I never usebool
for anything that can possibly be accessed across multiple link units—dynamic/static libraries, supplied object files—which basically means not in functions or classes that appear outside of header files. The practical answer, such as it is, is to use a pseudo-Boolean type, which is the size ofint
.
In short, he would agree with your approach.
Upvotes: 8
Reputation: 57036
If BOOL is some sort of integral type, and it always is, and BOOL is defined so that it works right, the standard conversions will automatically get it right. You can't quite use them interchangeably, but you can get close.
Use BOOL at the interface, where you have to talk to the Win32 API or whatever. Use bool everywhere else.
Upvotes: 12
Reputation: 24328
Another situation where you should use BOOL
: when implementing a callback function that takes or returns a BOOL
.
For example, EnumWindows()
takes a pointer to a callback function with the following signature:
BOOL CALLBACK EnumWindowsProc(
HWND hwnd,
LPARAM lParam
);
If you use bool
for this, you will have to typecast your function pointer.
Upvotes: 2
Reputation: 61703
Apparently, there's no good reason to use BOOL
:
http://blogs.msdn.com/oldnewthing/archive/2008/03/25/8334558.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/12/22/329884.aspx
Upvotes: 4