They are different in that if(ptr) is technically compiled into an integer/pointer comparison. There should be a special instruction for comparing whether an integer or pointer is 0 in x86 instructions set.

When returning a boolean from pointer it is first converted boolean and then a boolean comparison instruction is used. Therefore it is a bit slower. Generally the difference in speed is so little that you can just safely do this to avoid warnings:

int* ptr=0;
bool isValid()
{
return (bool)ptr;
}


At least that's the general idea.

More to the point, a bool has to have the value 0 or 1.[/quote]
Actually, a boolean can be represented by any word size (assumed 8 bytes since that's the smallest addressable memory size on current hardware), and by convention we define FALSE to be the value zero and TRUE to be any other value. (not that this invalidates your point, just some trivia).

More to the point, a bool has to have the value 0 or 1.

Actually, a boolean can be represented by any word size (assumed 8 bytes since that's the smallest addressable memory size on current hardware), and by convention we define FALSE to be the value zero and TRUE to be any other value. (not that this invalidates your point, just some trivia).
[/quote]You're talking about C.
In C++, which would be the language used here, there is an actual bool as a built-in type, where true is implicitly convertible to 1. Any nonzero is still treated as true of course.

Also, rather than ptr != 0, the preferabe way to do it is ptr != NULL, or if using C++0x, then ptr != nullptr

Actually, a boolean can be represented by any word size (assumed 8 bytes since that's the smallest addressable memory size on current hardware)...
[/quote]
Modern processors can still address individual bytes. The caching infrastructure might have a minimum threshold of data, but that doesn't mean that this is the minimum size of any unit of data.

Boolean values are typically 1 byte long on consumer hardware. Common exceptions include when they force structure padding or end up on the stack.

...and by convention we define FALSE to be the value zero and TRUE to be any other value.
[/quote]
For conditional expressions, sure. For boolean values, there are other considerations.

I believe the reason for forcing boolean expressions to true or false (rather than non-zero and 0) is to allow explicit boolean comparisons to be more reliable:

bool a = foo.isValid();
if(a == true) {
// "Unlikely" to get here without forcing boolean to true/false
}

bool b = /* ... */;
if(a == b) {
// Will we get here?
}

Sure, the above code could be written as:


bool a = foo.isValid();
if(a) {
// Will surely get here
}

bool b = /* ... */;
if((a && b) || !(a || b)) {
// We'll get here, but at what cost!!!11!1
}

I believe the first case represents an improvement over the explicit comparison, but the second case is considerably harder to comprehend (the intent is not clear).

(not that this invalidates your point, just some trivia).
[/quote]
I wouldn't recommend playing the C++ trivia game with SiCrane.

I'm not sure if the language specification even allows for this in the first place though, so it may just be of academic interest. But given how little details are specified sometimes and how much is open for implementation details, who knows...[/quote]
Well if the language doesn't support casting a byte/int/etc.. to a bool, you can always go ghetto:
1. allocate a byte (or whatever the size of a boolean in memory is on the target hardware).
2. write the integer "42" in it.
3. copy that memory into a boolean variable of your choice.
4.

When I was still learning programming a while ago I always wondered what would happen if I put something else than a true or a false into a boolean. Now I know. It's kind of fun messing around with some aspects of a language which aren't well-documented. To me anyway.

FWIW I did a quick test in C, then in Delphi. Turns out they don't handle booleans the same. C appears to only check the least significant bit for equality, whereas Delphi performs a complete byte comparison. Thus doing that hack in C will have no effect since it only ever looks at one bit, whereas it will utterly destroy program logic in Delphi. Check it out:


#include <stdio.h>
#include <stdbool.h>

int main( int argc, const char* argv[] )
{
bool a, b;
char v;

a = false;
b = false;

v = 43;
memcpy(&a, &v, 1);

v = 45;
memcpy(&b, &v, 1);

if (a == true)
{
printf("A = TRUE.\n");
}
else
{
printf("A = FALSE.\n");
}

if (b == true)
{
printf("B = TRUE.\n");
}
else
{
printf("B = FALSE.\n");
}
}