What's the point of BOOL?
-
I know this is a relatively irrelevant issue but it's been in my mind for long time: while in stardard C we use
boolfor the "true-or-false" value, in MFC we seeBOOLinstead, which is in fact a typedef of 32 bitinton win32 plateform(I think). Now my question is why. Seeing that in contrast withbool,BOOLdoes: 1, Occupy more memory storage, four bytes instead of one, not that matters a lot, but after all one has always been smaller than four since the first day when the human being could count. 2, Have pseudo-ambiguous data type comparing tobool, I said "pseudo" because the ambiguity is not for the compiler, but for the programmers themselves. In common sense I would thinkvoid Func(BOOL bVal)andvoid Func(int nVal)are different functions but they are in fact the same, so doing such overloading would generate compiler error. However,void Func(bool bVal)andvoid Func(int nVal)are indeed different and can be overloaded each other. Which one makes more sense to us? PerhapsBOOLwas introduced due to the fact that C++ allows an integer value to be treated as a "true-or-false", so withoutBOOL, thenif (65535 * 2) { ...; }would generate a "data truncate" warning since a one-byteboolcould not hold value of "65535 * 2", thus they came up with such a newBOOLwhich is capable of holding larger values. Hehe, personally, I never exam a pointer usingif (p) { ...; }, I always useif (p != NULL) { ...; }instead, which I think is a better practice. Anyway, I just couldn't see the necessity ofBOOLeven though I've been usingBOOLin MFC applications for years. -
I know this is a relatively irrelevant issue but it's been in my mind for long time: while in stardard C we use
boolfor the "true-or-false" value, in MFC we seeBOOLinstead, which is in fact a typedef of 32 bitinton win32 plateform(I think). Now my question is why. Seeing that in contrast withbool,BOOLdoes: 1, Occupy more memory storage, four bytes instead of one, not that matters a lot, but after all one has always been smaller than four since the first day when the human being could count. 2, Have pseudo-ambiguous data type comparing tobool, I said "pseudo" because the ambiguity is not for the compiler, but for the programmers themselves. In common sense I would thinkvoid Func(BOOL bVal)andvoid Func(int nVal)are different functions but they are in fact the same, so doing such overloading would generate compiler error. However,void Func(bool bVal)andvoid Func(int nVal)are indeed different and can be overloaded each other. Which one makes more sense to us? PerhapsBOOLwas introduced due to the fact that C++ allows an integer value to be treated as a "true-or-false", so withoutBOOL, thenif (65535 * 2) { ...; }would generate a "data truncate" warning since a one-byteboolcould not hold value of "65535 * 2", thus they came up with such a newBOOLwhich is capable of holding larger values. Hehe, personally, I never exam a pointer usingif (p) { ...; }, I always useif (p != NULL) { ...; }instead, which I think is a better practice. Anyway, I just couldn't see the necessity ofBOOLeven though I've been usingBOOLin MFC applications for years.I believe that prior to the C++98 standard, which MFC pre-dates, there was no "standard" built-in boolean type in C++ so MS defined their own (as many did back then). Im not sure when C got the built-in boolean type bool (if it does), probably in C99, otherwise C++98 should have had it pre-98. “Our solar system is Jupiter and a bunch of junk” - Charley Lineweaver 2002
-
I know this is a relatively irrelevant issue but it's been in my mind for long time: while in stardard C we use
boolfor the "true-or-false" value, in MFC we seeBOOLinstead, which is in fact a typedef of 32 bitinton win32 plateform(I think). Now my question is why. Seeing that in contrast withbool,BOOLdoes: 1, Occupy more memory storage, four bytes instead of one, not that matters a lot, but after all one has always been smaller than four since the first day when the human being could count. 2, Have pseudo-ambiguous data type comparing tobool, I said "pseudo" because the ambiguity is not for the compiler, but for the programmers themselves. In common sense I would thinkvoid Func(BOOL bVal)andvoid Func(int nVal)are different functions but they are in fact the same, so doing such overloading would generate compiler error. However,void Func(bool bVal)andvoid Func(int nVal)are indeed different and can be overloaded each other. Which one makes more sense to us? PerhapsBOOLwas introduced due to the fact that C++ allows an integer value to be treated as a "true-or-false", so withoutBOOL, thenif (65535 * 2) { ...; }would generate a "data truncate" warning since a one-byteboolcould not hold value of "65535 * 2", thus they came up with such a newBOOLwhich is capable of holding larger values. Hehe, personally, I never exam a pointer usingif (p) { ...; }, I always useif (p != NULL) { ...; }instead, which I think is a better practice. Anyway, I just couldn't see the necessity ofBOOLeven though I've been usingBOOLin MFC applications for years.Hi, I'm not absolutely sure, but i think the 'bool' is not part of ansi C. This could be the reason why microsoft introduced the BOOL, and it makes perfect sense. If my assuption is correct, then the question is: Why the hell didn't they define BOOL as char instead of int? greets, Jason
-
I know this is a relatively irrelevant issue but it's been in my mind for long time: while in stardard C we use
boolfor the "true-or-false" value, in MFC we seeBOOLinstead, which is in fact a typedef of 32 bitinton win32 plateform(I think). Now my question is why. Seeing that in contrast withbool,BOOLdoes: 1, Occupy more memory storage, four bytes instead of one, not that matters a lot, but after all one has always been smaller than four since the first day when the human being could count. 2, Have pseudo-ambiguous data type comparing tobool, I said "pseudo" because the ambiguity is not for the compiler, but for the programmers themselves. In common sense I would thinkvoid Func(BOOL bVal)andvoid Func(int nVal)are different functions but they are in fact the same, so doing such overloading would generate compiler error. However,void Func(bool bVal)andvoid Func(int nVal)are indeed different and can be overloaded each other. Which one makes more sense to us? PerhapsBOOLwas introduced due to the fact that C++ allows an integer value to be treated as a "true-or-false", so withoutBOOL, thenif (65535 * 2) { ...; }would generate a "data truncate" warning since a one-byteboolcould not hold value of "65535 * 2", thus they came up with such a newBOOLwhich is capable of holding larger values. Hehe, personally, I never exam a pointer usingif (p) { ...; }, I always useif (p != NULL) { ...; }instead, which I think is a better practice. Anyway, I just couldn't see the necessity ofBOOLeven though I've been usingBOOLin MFC applications for years.The original Win16 API defined a bunch of data types for use in the API. Things like
WORD,HWND,BOOL,LPARAM, etc., etc. date back to the 16-bit Windows days. This creates a type system that can be somewhat independent of the underlying hardware and operating system platform. This worked with some - though not complete - success when migrating code from Win16 to Win32 and from Win32 to Win64 (my understanding only, I have no direct Win64 experience). Back in the Win16 days, thebooltype was not part of the C or C++ language standards. It wasn't introduced until Visual C++ V5.0. SoBOOLwas defined in terms of types supported by the compilers of the day. The definition has probably remained to ensure backward compatibility with both code and data. Brad -
I know this is a relatively irrelevant issue but it's been in my mind for long time: while in stardard C we use
boolfor the "true-or-false" value, in MFC we seeBOOLinstead, which is in fact a typedef of 32 bitinton win32 plateform(I think). Now my question is why. Seeing that in contrast withbool,BOOLdoes: 1, Occupy more memory storage, four bytes instead of one, not that matters a lot, but after all one has always been smaller than four since the first day when the human being could count. 2, Have pseudo-ambiguous data type comparing tobool, I said "pseudo" because the ambiguity is not for the compiler, but for the programmers themselves. In common sense I would thinkvoid Func(BOOL bVal)andvoid Func(int nVal)are different functions but they are in fact the same, so doing such overloading would generate compiler error. However,void Func(bool bVal)andvoid Func(int nVal)are indeed different and can be overloaded each other. Which one makes more sense to us? PerhapsBOOLwas introduced due to the fact that C++ allows an integer value to be treated as a "true-or-false", so withoutBOOL, thenif (65535 * 2) { ...; }would generate a "data truncate" warning since a one-byteboolcould not hold value of "65535 * 2", thus they came up with such a newBOOLwhich is capable of holding larger values. Hehe, personally, I never exam a pointer usingif (p) { ...; }, I always useif (p != NULL) { ...; }instead, which I think is a better practice. Anyway, I just couldn't see the necessity ofBOOLeven though I've been usingBOOLin MFC applications for years.=[ Abin ]= wrote: In common sense I would think void Func(BOOL bVal) and void Func(int nVal) are different functions but they are in fact the same, so doing such overloading would generate compiler error. However, void Func(bool bVal) and void Func(int nVal) are indeed different and can be overloaded each other. I have ran into this several times and had to use bool. John
-
I know this is a relatively irrelevant issue but it's been in my mind for long time: while in stardard C we use
boolfor the "true-or-false" value, in MFC we seeBOOLinstead, which is in fact a typedef of 32 bitinton win32 plateform(I think). Now my question is why. Seeing that in contrast withbool,BOOLdoes: 1, Occupy more memory storage, four bytes instead of one, not that matters a lot, but after all one has always been smaller than four since the first day when the human being could count. 2, Have pseudo-ambiguous data type comparing tobool, I said "pseudo" because the ambiguity is not for the compiler, but for the programmers themselves. In common sense I would thinkvoid Func(BOOL bVal)andvoid Func(int nVal)are different functions but they are in fact the same, so doing such overloading would generate compiler error. However,void Func(bool bVal)andvoid Func(int nVal)are indeed different and can be overloaded each other. Which one makes more sense to us? PerhapsBOOLwas introduced due to the fact that C++ allows an integer value to be treated as a "true-or-false", so withoutBOOL, thenif (65535 * 2) { ...; }would generate a "data truncate" warning since a one-byteboolcould not hold value of "65535 * 2", thus they came up with such a newBOOLwhich is capable of holding larger values. Hehe, personally, I never exam a pointer usingif (p) { ...; }, I always useif (p != NULL) { ...; }instead, which I think is a better practice. Anyway, I just couldn't see the necessity ofBOOLeven though I've been usingBOOLin MFC applications for years.I too am annoyed by two versions of bool. What’s worse is if you use bool the compiler tells you about a performance issue. And with today’s processors I am not sure which one is really faster. Memory is slow compared to cpu cycles (disk is several orders of magnitude slower) so avoiding additional code bloat may be faster than executing a few extra cycles of cpu time... As others have pointed out BOOL is part of windows and not just MFC. John
-
I know this is a relatively irrelevant issue but it's been in my mind for long time: while in stardard C we use
boolfor the "true-or-false" value, in MFC we seeBOOLinstead, which is in fact a typedef of 32 bitinton win32 plateform(I think). Now my question is why. Seeing that in contrast withbool,BOOLdoes: 1, Occupy more memory storage, four bytes instead of one, not that matters a lot, but after all one has always been smaller than four since the first day when the human being could count. 2, Have pseudo-ambiguous data type comparing tobool, I said "pseudo" because the ambiguity is not for the compiler, but for the programmers themselves. In common sense I would thinkvoid Func(BOOL bVal)andvoid Func(int nVal)are different functions but they are in fact the same, so doing such overloading would generate compiler error. However,void Func(bool bVal)andvoid Func(int nVal)are indeed different and can be overloaded each other. Which one makes more sense to us? PerhapsBOOLwas introduced due to the fact that C++ allows an integer value to be treated as a "true-or-false", so withoutBOOL, thenif (65535 * 2) { ...; }would generate a "data truncate" warning since a one-byteboolcould not hold value of "65535 * 2", thus they came up with such a newBOOLwhich is capable of holding larger values. Hehe, personally, I never exam a pointer usingif (p) { ...; }, I always useif (p != NULL) { ...; }instead, which I think is a better practice. Anyway, I just couldn't see the necessity ofBOOLeven though I've been usingBOOLin MFC applications for years.=[ Abin ]= wrote: Anyway, I just couldn't see the necessity of BOOL even though I've been using BOOL in MFC applications for years. I think it is just matter of who comes first and backward compatibility. For example, you cannot use type bool in a com interface (I think).[
My articles and software tools
-
I know this is a relatively irrelevant issue but it's been in my mind for long time: while in stardard C we use
boolfor the "true-or-false" value, in MFC we seeBOOLinstead, which is in fact a typedef of 32 bitinton win32 plateform(I think). Now my question is why. Seeing that in contrast withbool,BOOLdoes: 1, Occupy more memory storage, four bytes instead of one, not that matters a lot, but after all one has always been smaller than four since the first day when the human being could count. 2, Have pseudo-ambiguous data type comparing tobool, I said "pseudo" because the ambiguity is not for the compiler, but for the programmers themselves. In common sense I would thinkvoid Func(BOOL bVal)andvoid Func(int nVal)are different functions but they are in fact the same, so doing such overloading would generate compiler error. However,void Func(bool bVal)andvoid Func(int nVal)are indeed different and can be overloaded each other. Which one makes more sense to us? PerhapsBOOLwas introduced due to the fact that C++ allows an integer value to be treated as a "true-or-false", so withoutBOOL, thenif (65535 * 2) { ...; }would generate a "data truncate" warning since a one-byteboolcould not hold value of "65535 * 2", thus they came up with such a newBOOLwhich is capable of holding larger values. Hehe, personally, I never exam a pointer usingif (p) { ...; }, I always useif (p != NULL) { ...; }instead, which I think is a better practice. Anyway, I just couldn't see the necessity ofBOOLeven though I've been usingBOOLin MFC applications for years.=[ Abin ]= wrote: in stardard C we use bool for the "true-or-false" value Before I started C++ programming in the mid 90's, c did not have a bool type. One of the first things I did in every program was typedef bool or #define TRUE=1 FALSE=0