Balog Pal wrote:
>
> "Jack Klein" <jackklein@spamcop.net> wrote in message news:ht8pgt4io2gl8r93asutvs807rc8ff09sv@4ax.com...
>
> > You seem to think that this is an accidental loophole in the standard
> > into which you can stumble by accident.  Instead it is deliberate, by
> > design.
> >
> > true and false have precisely defined relationships with all
> > arithmetic types:  any non-zero value is true and only exactly zero is
> > false.
>
> I don't think so. The things you write ARE not true and false. But on need, integral expression of the respective values can be CONVERTED to type bool, and take the value of true or false. I
Not only integral expressions, but also floating point values,
enumerations, pointers, and pointers to members. And in all cases, they
are converted to bool as if by the expression "!=T(0)", where T is the
type of the expression. However, I am in agreement with your main point;
these types are convertable to 'true' or 'false', but that doesn't meant
that they ARE 'true' or 'false'. The fact that they are so convertible
is a reasonable but essentially arbitrary convention.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Jack Klein" <jackklein@spamcop.net> wrote in message news:ht8pgt4io2gl8r93asutvs807rc8ff09sv@4ax.com...

> You seem to think that this is an accidental loophole in the standard
> into which you can stumble by accident.  Instead it is deliberate, by
> design.
>
> true and false have precisely defined relationships with all
> arithmetic types:  any non-zero value is true and only exactly zero is
> false.

I don't think so. The things you write ARE not true and false. But on need, integral expression of the respective values can be CONVERTED to type bool, and take the value of true or false. I remember in the early Borland compilers a bool variable could retain a non-1, non-0 value, and still treated as true, avoiding some penalty in speed, and an uninitialised bool always behaved "correctly" as a side effect. But I'm sure the standard disallows any of those things now.

> The relationship with pointers is quite intentional.  A null pointer
> is false (can't possibly point to any object at all) and a non-null
> pointer is true.

No way. A pointer is a pointer. Poiters are not an integral type even less a bool. However a pointer to bool conversion also exists by comparing the pointer value with the null_pointer_constant. The fact that for npc we use integer 0 and false is too integer 0 is a mere conicidence. I we had a truly abstract npc, having no integer value, and usable only as a pointer, or if npc would have value 42 instead of 0, a null pointer would still convert to false, and a non-null one to true.

And this path of conversions I consider natural, and meaningful. Quite many programs use

if(p)  // instead of if(p == NULL)  or if (p == 0)

Also, I can write

bool b = p; // use the same conversion.

However, The following is rejected:

int i = p; // can't convert pointer to integer.

An indirect path using pointer->bool->int is fortunately inhibited.

My problem is the conversion to the other way.

Integers do not, and should not convert to pointer:

P * p = i; // rejected;

Except for a very special case, where i is a consant expression, and also has a value of 0 (that is, equal to the npc).

const int i = 0;
P * p = i;  // that should compile.
P * p = 0; // that one too

There were discussions on why there is not a separate npc type, and wh treating integer 0 this special way is bad. It may be even changed in the future, and usage of 0 being decrepated, but having all the code around using the expressions above that's next to impossible ever remove.

> All of these are, and should have, the same meaning:
>
> FOO *pFoo = 0;
> FOO *pFoo = NULL;

Those are okey. Not having other stuff, 0 is considered npc, and threated that way. Note however that it's still a breach in the type system. But at least one most programmers are aware of.  I read thaat "set pFoo to the null_pointer_constant", and that is what actually happens. (the binary rep of pFoo after the assignmennt may be anything, and is nothing like an all-zero bit pattern on many systems.)

> FOO *pFoo = false;

Not this one. What that is _supposed_ to mean? false is a member of th boolean range, that should have no telation to any pointer thing. Consider this:

enum Colors {red, green, blue};
FOO *pFoo = green;  // does that make sense? Not for me
FOO *pFoo = red;     // neither this one

Even if red accidentally has the value of 0 I do not think of it as a numeric value, but as a special member. I require the compiler keeps the usage in cage.

> Consider, after any of the above declarations/initializations:
>
>   if (some condition)
>      pFoo = new /* or new [] whatever */;
>
> Then sometime later:
>
> if (pFoo != 0)
> if (pFoo != NULL)
> if (pF00 != false)
> if (pFoo)
>
> ....should and do all mean the same thing.

1, 2 and 4 are specil cases ordered by the standard to work the way we know. For 4 it is an implicit conversion, and the first two are consequence of 0 chosen as npc.

For the third, the comparision is way more tricky. It is based not on a direct comparision, but on the "pFoo is equal npc" and "false is qual npc" and we compare those. Before you start thinking about transition of equality consider a parallel example:

struct A {   operator int() {return 42;} };
struct B {   operator int() {return 42;} };

if(A == B) ; // quite a bullshit comparision.

But you can think: A converts to integer 0, B too converts to integer 42, so those classes are equal. Same story as the "any pointer" -> npc -> 0, and the "false" -> 0.

> Why do you think it should not be allowed?

I hope that gives an explanation. :)

(BTW I may misuse some termini, corrections are welcome. )

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Balog Pal wrote:
>
> Those automatic integral promotions/conversions are generally good but sometimes they appear to bite.
>
> As
>
> FOO * pFoo = false; // compiles silently
>
> I think this is something pretty bad.
>
> As a pretty late addition C++ made bool a type, and defined those true & false constants. I wonder having such a change why didn't they go the whole way then. with much more guards around this type, preventing such misuse.

But bool is an integral type by definition and false evaluates to zero.
After all, the bond between boolean and integer values is very tight
from the early days of C, and changing this would probably have been
difficult.

Best regards,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I disagree here.  Converting pointers to bool is good and proper.  But
converting a bool to a pointer like that, it never makes logical sense.  I
suspect that the problem is strickly the compiler; my compiler won't compile
the line.

"Jack Klein" <jackklein@spamcop.net> wrote in message
news:ht8pgt4io2gl8r93asutvs807rc8ff09sv@4ax.com...
> On Wed, 23 May 2001 07:17:02 GMT, "Balog Pal" <pasa@lib.hu> wrote in
> comp.std.c++:
> You seem to think that this is an accidental loophole in the standard
> into which you can stumble by accident.  Instead it is deliberate, by
> design.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Wed, 23 May 2001 07:17:02 GMT, "Balog Pal" <pasa@lib.hu> wrote in
comp.std.c++:

> Those automatic integral promotions/conversions are generally good but sometimes they appear to bite.
>
> As
>
> FOO * pFoo = false; // compiles silently
>
> I think this is something pretty bad.
>
> As a pretty late addition C++ made bool a type, and defined those true & false constants. I wonder having such a change why didn't they go the whole way then. with much more guards around this type, preventing such misuse.
>
> Paul

You seem to think that this is an accidental loophole in the standard
into which you can stumble by accident.  Instead it is deliberate, by
design.

true and false have precisely defined relationships with all
arithmetic types:  any non-zero value is true and only exactly zero is
false.

The relationship with pointers is quite intentional.  A null pointer
is false (can't possibly point to any object at all) and a non-null
pointer is true.

All of these are, and should have, the same meaning:

FOO *pFoo = 0;
FOO *pFoo = NULL;
FOO *pFoo = false;

Consider, after any of the above declarations/initializations:

  if (some condition)
     pFoo = new /* or new [] whatever */;

Then sometime later:

if (pFoo != 0)
if (pFoo != NULL)
if (pF00 !false)
if (pFoo)

....should and do all mean the same thing.

Why do you think it should not be allowed?

--
Jack Klein
Home: http://JK-Technology.Com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Those automatic integral promotions/conversions are generally good but sometimes they appear to bite.

As

FOO * pFoo = false; // compiles silently

I think this is something pretty bad.

As a pretty late addition C++ made bool a type, and defined those true & false constants. I wonder having such a change why didn't they go the whole way then. with much more guards around this type, preventing such misuse.

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]