How come in the Win32 API, you're supposed to use BOOL instead of bool, TRUE instead of true, etc. It just seems unnecessary to me.
How come in the Win32 API, you're supposed to use BOOL instead of bool, TRUE instead of true, etc. It just seems unnecessary to me.
Because the API is written in C.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
OK, that makes sense
It will make substantially less sense when you find that most functions returning a `BOOL' actually use a three value system.
Soma
I would say it IS necessary. Whenever you use a library, you should stick to its rules and typedefs as they might change in the future.
Actually, WinAPI's BOOL is defined as int (in my implementation), so it's not the same as bool. Whenever I write WinAPI wrappers I use its typedefs, even those for INTs (some WinAPI's parameters are UINTs some DWORDs those can be different in practise).
Also, when a WinAPI's function returns BOOL, you shall not compare it with TRUE when the documentation says "function returns 0 on success, otherwise non-zero"
Last edited by kmdv; 08-25-2010 at 04:20 AM.
I think the point is that it uses BOOL instead of bool because the Windows API was written for C90, and C90 doesn't have the bool type.
Therefore, the creators of the API had to invent their own boolean type, which was named BOOL. That's all there is to it.
It was a discussion of whether it was fine using bool instead of BOOL when dealing with these functions, I believe. I could be wrong, though.
Originally Posted by Adak
Note that there might be also a structure containing a BOOL field, and a WORD following. Data alignment issues must be taken into consideration as well.
That has tripped up quite a few, yes (the "GetMessage catastrophe", to wit).Anyway, the documentation will (should, anyway) say so, if it does.
Why so?Note that there might be also a structure containing a BOOL field, and a WORD following. Data alignment issues must be taken into consideration as well.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
I beg to differ. The entire Win32 API is built around typedefs, so even if there were a native bool type, it would probably have been wrapped up in a neat typedef.
iMalc: Your compiler doesn't accept misspellings and bad syntax, so why should we?
justin777: I have no idea what you are talking about sorry, I use a laptop and there is no ascii eject or something
That is possible. The fact that BOOL is really int since there's no native bool type still remains, though.
So the reason of typedefing BOOL was not only that there was no native bool type back then. There is also INT, FLOAT etc.Why so?Note that there might be also a structure containing a BOOL field, and a WORD following. Data alignment issues must be taken into consideration as well.
Why not typedefed as BYTE...That is possible. The fact that BOOL is really int since there's no native bool type still remains, though.
Last edited by kmdv; 08-25-2010 at 12:22 PM.
That doesn't answer my question: what has it got to do with alignment?
Because C implicitly promotes stack arguments smaller than int to an int, maybe?
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
BOOL seemed unnecessary to one of the posters. I said it might have been typedefed for such purposes also.That doesn't answer my question: what has it got to do with alignment?
Maybe, but this type might be used in structs too (might, I don't know if there is even one struct that does)Because C implicitly promotes stack arguments smaller than int to an int, maybe?
So.. it's all I had to say
