TRUE vs true or FALSE vs false
in [MFC]
|
From: Joseph M. Newcomer on 16 Jun 2010 12:17 See below... On Wed, 16 Jun 2010 10:36:08 -0500, Stephen Myers <""StephenMyers\"@discussions(a)microsoft.com"> wrote: > >JCO wrote: >> int x = sizeof(true); >> int y = sizeof(TRUE); >> >> x is 1 >> y is 4 >> Okay so the size if different? >> I always attempt to use lowercase when possible. >> >> "r norman" <r_s_norman(a)comcast.net> wrote in message >> news:haoh16pjir0uk12jdjdrdih03gi4g0kfgp(a)4ax.com... >>> On Wed, 16 Jun 2010 09:23:44 -0500, "JCO" <someone(a)somewhere.com> >>> wrote: >>> >>>> What exactly is the difference. This has always bothered me that >>>> this is >>>> the case. I've noticed that you cannot substitute one for the >>>> other. I'm >>>> guessing TRUE was the original way of doing things before "true" came >>>> along? >>>> The same case can be made with FALSE vs false. >>>> >>> >>> Compare sizeof(TRUE) with sizeof(true). >>> >>> I believe TRUE/FALSE were introduced before true/false became standard >>> in C (and then C++). Once they were well entrenched in the Windows >>> libraries it would have broken too much old code to change everything >>> to be consistent. >> > >TRUE and FALSE are the original C way of doing things. **** No. This has nothing to do with the C language and everything to do with the Windows header files. **** > >Windows defines a BOOL data type which is a 32 integer. This >corresponds to TRUE and FALSE. **** No, a data type cannot correspond to a value. The *type* is 32-bit integer. There are two defined literal values, TRUE (1) and FALSE(0). **** > >You should be able to find #define typedef or enum definitions for BOOL, >TRUE and FALSE. **** windef.h **** > >The bool data type is a relatively recent addition and is supported >internally by the compiler. It's size is normally a byte. **** It exists only in the C++ language at the moment. It is scheduled to exist in the next C standard, if that comes out in this century. The joke is that it used to be called the "C 0x" standard because it was going to be released sometime before 2010. Now it is known as the "C xx" standard, the "C 2x0x" standard, and the "C 2xxx" standard, since there seems to be little hope of any agreement about its release date. I heard one wag refer to it as the "C Fry" standard, since it may not come out until Philip J. Fry is defrosted. joe **** > >HTH >Steve Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Webber on 16 Jun 2010 13:21 "JCO" <someone(a)somewhere.com> wrote in message news:eBBvG#VDLHA.4308(a)TK2MSFTNGP04.phx.gbl... > What exactly is the difference. This has always bothered me that this is > the case. I've noticed that you cannot substitute one for the other. I'm > guessing TRUE was the original way of doing things before "true" came > along? The same case can be made with FALSE vs false. I'll endorse everything Joe just said, and add that my programs are filled with both BOOL and bool. Anywhere in the vicinity of where a Windows or MFC API function is called, then it makes sense to use BOOL. Elsewhere in classes which don't have much contact with the API then bool always seems more elegant. Having both is a mess, but one gets used to it. Except class/struct member variables: I like to keep my variable boundaries neat, so I'd have (say) two members which are BOOL and int, rather than bool and int, and thus avoid invisible packing bytes. In many cases this is just control freakery on my part and it doesn't matter at all - but it makes me feel happier :-( Oh, and when I have a function which returns a BOOL I *always* make it return TRUE or FALSE. Never return (a==b); always: return (a==b)? TRUE: FALSE; But of course I never test equality with TRUE or FALSE for all the reasons Joe gives, so it's just me being paranoidally neat again. :-( Strange really, because outside of programming I never have any urge whatever to be tidy, or line the knives and forks up, or whatever :-) Dave -- David Webber Mozart Music Software http://www.mozart.co.uk For discussion and support see http://www.mozart.co.uk/mozartists/mailinglist.htm
From: Doug Harrison [MVP] on 16 Jun 2010 14:00 On Wed, 16 Jun 2010 09:23:44 -0500, "JCO" <someone(a)somewhere.com> wrote: >What exactly is the difference. This has always bothered me that this is >the case. I've noticed that you cannot substitute one for the other. I'm >guessing TRUE was the original way of doing things before "true" came along? >The same case can be made with FALSE vs false. Thanks to standard conversions, you almost always *can* substitute the *constants* one for the other. That's less true for the *types*. To understand the difference between the constants, start with the types. The BOOL type is an ancient Windows typedef for int: typedef int BOOL; #define TRUE 1 #define FALSE 0 It's basically a code comment used to indicate boolean usage.[*] This was about the best you could do in the C language of the time, and it's consistent with the behavior of the relational operators, which yield ints equal to 1 or 0. Note, however, that all non-zero values are considered "true" in C and also when using BOOL, not just TRUE. In contrast, the C++ bool type is a proper boolean type. The only values a bool can hold are true and false. In expressions, true converts to 1 and false to 0, which is why you can normally use true and false interchangeably with TRUE and FALSE. Going the other way: bool x = y; // y is non-bool Assigning a non-bool value to a bool is equivalent to this: bool x = y != 0; The result of a relational operator is true or false in C++, so non-zero values get converted to true, which is done to maintain the C notion that non-zero means true. This is a big difference between bool and BOOL. If you were to write: BOOL x = 5; Then x would contain the value 5 (still "true", but not TRUE). If you were to write: BOOL x = INT64_MAX; Then x would contain 0 due to integer truncation. However, if you were to change the type to bool, x would contain true in both cases. Besides behavioral differences, there is a size difference to consider. Obviously, sizeof(BOOL) == sizeof(int). However, sizeof(bool) is 1 in Visual C++ and most other implementations, making it the same size as a char. I said earlier that the types are less interchangeable than the constants. This is true simply because they are different types, which means you can't pass the address of a bool where the address of a BOOL is required, using a BOOL parameter to try to override a function that uses a bool parameter won't work, and so forth. So how to use all this? When there is a choice (see paragraph above for cases for which there is not a choice, and also consider consistency when writing things like Windows API wrappers), use bool instead of BOOL. It's better behaved and smaller. As for the constants, it is very unlikely you will run into a situation for which TRUE/FALSE vs. true/false matters, so use whatever you want. I use true/false pretty much exclusively. If there were to be a problem, it would be due to ambiguity resulting from something like stupidly designed function overloads, and it wouldn't be a silent error. [*] Except for the GetMessage return value, which uses BOOL for three states. Then there's the return value for CSingleLock::Lock, which IIRC uses BOOL when there are three possible outcomes, except it just improperly converts two of them into TRUE. There may be more BOOL abuse I'm not aware of. -- Doug Harrison Visual C++ MVP
From: Joseph M. Newcomer on 16 Jun 2010 15:55 Added comments below... On Wed, 16 Jun 2010 18:21:53 +0100, "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote: > > > >"JCO" <someone(a)somewhere.com> wrote in message >news:eBBvG#VDLHA.4308(a)TK2MSFTNGP04.phx.gbl... > >> What exactly is the difference. This has always bothered me that this is >> the case. I've noticed that you cannot substitute one for the other. I'm >> guessing TRUE was the original way of doing things before "true" came >> along? The same case can be made with FALSE vs false. > >I'll endorse everything Joe just said, and add that my programs are filled >with both BOOL and bool. Anywhere in the vicinity of where a Windows or >MFC API function is called, then it makes sense to use BOOL. Elsewhere in >classes which don't have much contact with the API then bool always seems >more elegant. Having both is a mess, but one gets used to it. > >Except class/struct member variables: I like to keep my variable boundaries >neat, so I'd have (say) two members which are BOOL and int, rather than bool >and int, and thus avoid invisible packing bytes. In many cases this is >just control freakery on my part and it doesn't matter at all - but it makes >me feel happier :-( > >Oh, and when I have a function which returns a BOOL I *always* make it >return TRUE or FALSE. Never > > return (a==b); > >always: > > return (a==b)? TRUE: FALSE; **** I know this is a bit over-compulsive, but I write the same kind of code for the same reasons. I will also write button.SetCheck(value ? BST_CHECKED : BST_UNCHECKED); I have no idea why Microsoft even bothers to tell the checkbox button values of 0, 1 or 2 instead of giving the symbolic names. The number of times I've seen code of the form button.SetCheck(value); is amazing. Back in WIndows 3.1, and value not 0 or 2 was treated as 1 (and for non-tri-state buttons, 2 was treated as 1), but in 32-bit Windows (including the imitation operating systems of the 9x family) the value had to be 0, 1 or 2. I used to spend time fixing code that had worked under Windows 3.1 because 'vaue' could be anything and often was. And clients would say "We ported this working code to 32-bit and it stopped working" and I had to explain "You ported code that was never right from a system that worked incorrectly to a system that worked correctly". ***** > >But of course I never test equality with TRUE or FALSE for all the reasons >Joe gives, so it's just me being paranoidally neat again. :-( Strange >really, because outside of programming I never have any urge whatever to be >tidy, or line the knives and forks up, or whatever :-) **** Any good programmer could be successfully accused of having obsessive-compulsive disorder (OCD). A friend of mine, one of the very best programmers I know, related once that he was taking medication to help his OCD, and I pointed out that was what made him one of the best of the best. He said "Yes, but it was spilling into everyday life". Like you, I am not overly compulsive in most other areas of my life; I don't wash my hands 100 times a day, or sort my sock drawer by spectral color, or things like that; my office is a total shambles. But I really do apply tidiness guidelines to my code. And in that, I am definitely obsessive. joe ***** > >Dave Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Cholo Lennon on 16 Jun 2010 17:01
On 16/06/2010 13:17, Joseph M. Newcomer wrote: > See below... > On Wed, 16 Jun 2010 10:36:08 -0500, Stephen Myers > <""StephenMyers\"@discussions(a)microsoft.com"> wrote: > >> >> JCO wrote: >>> int x = sizeof(true); >>> int y = sizeof(TRUE); >>> >>> x is 1 >>> y is 4 >>> Okay so the size if different? >>> I always attempt to use lowercase when possible. >>> >>> "r norman"<r_s_norman(a)comcast.net> wrote in message >>> news:haoh16pjir0uk12jdjdrdih03gi4g0kfgp(a)4ax.com... >>>> On Wed, 16 Jun 2010 09:23:44 -0500, "JCO"<someone(a)somewhere.com> >>>> wrote: >>>> >>>>> What exactly is the difference. This has always bothered me that >>>>> this is >>>>> the case. I've noticed that you cannot substitute one for the >>>>> other. I'm >>>>> guessing TRUE was the original way of doing things before "true" came >>>>> along? >>>>> The same case can be made with FALSE vs false. >>>>> >>>> >>>> Compare sizeof(TRUE) with sizeof(true). >>>> >>>> I believe TRUE/FALSE were introduced before true/false became standard >>>> in C (and then C++). Once they were well entrenched in the Windows >>>> libraries it would have broken too much old code to change everything >>>> to be consistent. >>> >> >> TRUE and FALSE are the original C way of doing things. > **** > No. This has nothing to do with the C language and everything to do with the Windows > header files. > **** >> >> Windows defines a BOOL data type which is a 32 integer. This >> corresponds to TRUE and FALSE. > **** > No, a data type cannot correspond to a value. The *type* is 32-bit integer. There are > two defined literal values, TRUE (1) and FALSE(0). > **** >> >> You should be able to find #define typedef or enum definitions for BOOL, >> TRUE and FALSE. > **** > windef.h > **** >> >> The bool data type is a relatively recent addition and is supported >> internally by the compiler. It's size is normally a byte. > **** > It exists only in the C++ language at the moment. It is scheduled to exist in the next C > standard, if that comes out in this century. The joke is that it used to be called the "C > 0x" standard because it was going to be released sometime before 2010. Now it is known as > the "C xx" standard, the "C 2x0x" standard, and the "C 2xxx" standard, since there seems > to be little hope of any agreement about its release date. I heard one wag refer to it as > the "C Fry" standard, since it may not come out until Philip J. Fry is defrosted. > joe > **** C99 already has a boolean type: _Bool (see C99 specification 6.25, 6.3.1.2, 6.4.1 and 6.7.2) It also has a group of macros to manage the bool behavior (bool, false and true, see stdbool.h header, C99 specification 7.16) Regards -- Cholo Lennon Bs.As. ARG >> >> HTH >> Steve > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |