BOOL instead of bool?

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. ;)

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"

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.

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.

Quote:

---

Originally Posted by phantomotap

It will make substantially less sense when you find that most functions returning a `BOOL' actually use a three value system.

Soma

---

That has tripped up quite a few, yes (the "GetMessage catastrophe", to wit). :p Anyway, the documentation will (should, anyway) say so, if it does.

Quote:

---

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 so?

Quote:

---

Originally Posted by Elysia

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.

---

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.

That is possible. The fact that BOOL is really int since there's no native bool type still remains, though.

Quote:

---

Quote:

---

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 so?

---

So the reason of typedefing BOOL was not only that there was no native bool type back then. There is also INT, FLOAT etc.

Quote:

---

That is possible. The fact that BOOL is really int since there's no native bool type still remains, though.

---

Why not typedefed as BYTE...

Quote:

---

Originally Posted by kmdv

So the reason of typedefing BOOL was not only that there was no native bool type back then. There is also INT, FLOAT etc.

---

That doesn't answer my question: what has it got to do with alignment?

Quote:

---

Originally Posted by kmdv

Why not typedefed as BYTE...

---

Because C implicitly promotes stack arguments smaller than int to an int, maybe?

Quote:

---

That doesn't answer my question: what has it got to do with alignment?

---

BOOL seemed unnecessary to one of the posters. I said it might have been typedefed for such purposes also.

Quote:

---

Because C implicitly promotes stack arguments smaller than int to an int, maybe?

---

Maybe, but this type might be used in structs too (might, I don't know if there is even one struct that does)



So.. it's all I had to say