Re: bool or BOOL in MFC projects

But if(p) is a type violation. It says that a pointer is a bool. I always write the ==
NULL because that is not a type violation. It is a most unfortunate misfeature of C that
it allows non-boolean results to be treated as boolean expressions. Those of us who
trained on languages that were designed rather than thrown together by accident find the
confusion of non-boolean values with boolean values to be really confusing. Every
language in history that supported a boolean type made it clear that it was not an integer
or pointer, or in any way interchangeable with integer, pointer, or any other type. Then
C came along and because they were defining a "minimal" language didn't think a boolean
data type added anything. By 1976 I had defined a boolean type with constants TRUE and
FALSE, and I coded with that header file until I started programming in Windows in 1990
and had the BOOL type. So in over 30 years, I have never accepted if(p) to mean a "null
pointer test".
joe
On Wed, 19 Dec 2007 09:22:44 -0000, "David Webber" <dave@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:


"David Lowndes" <DavidL@xxxxxxxxxxxxxxx> wrote in message
news:kfrgm35tmrvee99ei8pgh9k5uq5vtdd3b0@xxxxxxxxxx

I recall being bitten by code like this:

if ( Api() == TRUE )
{..
}

... which failed under Windows 95 because the API returned a non-zero
value rather than TRUE.

A few thoughts:

Yes. In fact I avoid "==TRUE" like the plague, and by extension "==true"
though that should be safer I guess.

But the whole point of the Boolean concept is that you can use

BOOL b;
...
if( b )

Writing if( b==TRUE ) is a tautology in the sense that "b==TRUE" is an
expression which (in principle) evaluates to a Boolean, which you are then
testing with if() :-)

In fact, correct me if I am wrong, expressions comparing integers a<b
a==b return an integer 1 or 0 don't they? My 1991 copy of Stroustrup
predates "bool", and so I am never sure about things like this :-)
They haven't changed it have they? If not, the BOOL concept appears
implicit in the language, even if it is Windows which actually defines the
type BOOL.

[I vaguely remember that a==b was not at one stage required to return 1 if
true, but maybe that is prehistory.]

Anyway the ability of the if( ... ) to accept or reject the operand on the
basis of being zero or non-zero is one of the extremely useful facets of
C/C++ and I would never write for a pointer p if( p==NULL ) or the other
favourite if( NULL==p ) because if( p ) is perfectly clear!

Just my 2d worth,

Dave
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Paying developers to get features faster
    ... treated as a bool, ... pointer comparison and the boolean result of the pointer comparison. ... Well, if the language is guaranteed to evaluate the NULL pointer as 0, ...
    (comp.os.linux.misc)
  • Re: Paying developers to get features faster
    ... treated as a bool, ... pointer comparison and the boolean result of the pointer comparison. ... Well, if the language is guaranteed to evaluate the NULL pointer as 0, ...
    (comp.os.linux.development.system)
  • Re: Paying developers to get features faster
    ... treated as a bool, ... pointer comparison and the boolean result of the pointer comparison. ... Well, if the language is guaranteed to evaluate the NULL pointer as 0, ...
    (comp.security.misc)
  • Re: Paying developers to get features faster
    ... treated as a bool, ... pointer comparison and the boolean result of the pointer comparison. ... Well, if the language is guaranteed to evaluate the NULL pointer as 0, ...
    (comp.os.linux.security)
  • Re: Weird problem calling DLL
    ... afaik a Delphi boolean is not ... always equal to a bool also. ... *neither* language defines the binary representation of the types. ...
    (comp.lang.pascal.delphi.misc)