I would prefer to see if(pointer != NULL) vs if(pointer). The pointer isn't truly a boolean - it is easier to see what you mean if you specify a conditional. Just my opinion...

I prefer to see if(pointer) because it is idiomatic:

Data* data = NULL;// ... // sekret codes! will the pointer be assigned or not? :o// ...if (data) { // "if we have data"  data.doSomething();}

But it's also nicer to avoid nulls where possible, especially via the use of a Null Object pattern where it makes sense - because extra if's are icky in their own way too.

In C++ one is generally suggested to just use 0 anyways, since C headers like to set NULL to ((void*)0), which doesn't work properly in C++ ( because there's no implicit conversion to T* from void*).

...at least until the nullptr proposal gets accepted ;)

Quote:Original post by ehmdjii
thank you all!

so when i leave the pointer uninitialized like in the above example, it will still evaluate to true, cause it points to random memory?

No, it will randomly be either true or false. Although the random value needs to be 0 for it to evaluate to false, it is very common for this to happen with variables allocated on the stack. Always initialise your variables, unless you have a very good reason not to.

Quote:Original post by Zahlman

Data* data = NULL;
...
if (data) { // "if we have data"
data.doSomething();

There should be a "->" instead of a "." since it's a pointer.

Quote:Original post by Extrarius
Nathan Baum: Of course. I'm not sure why I didn't think to look up 'if'. Still, IMO it is interesting that "if((int)Pointer){}"(or even "if((intptr_t)Pointer){}") is apparently implementation dependent, while "if(Pointer){}" is not.

Well, it's because C and C++ are engaging in a bit of doublethink with regards to '0'.

0 is both an integer constant, and the null pointer constant. C++ sensibly doesn't define conditional expressions in terms of comparison to 0, but neither language is prepared to have distinct syntax for a null pointer constant.

Additionally, there's no rule that says the null pointer has to point at the first byte of memory. The null pointer might point at some other location. It only needs to be distinct from any other pointer. If you're allowed to have a non-null pointer which points at the first byte, then obviously the null pointer can't point there.

On Intel architectures at least, location zero is a real memory location and contains the start of the interrupt table, which you'd have to be able to access if you were writing a kernel, say.

Of course, for efficiency reasons it's better to use a zero, since comparisons to it can be done very quickly on most architectures. You'd probably use assembly for access the interrupt table, where you'd just have to know whether a 0 was a null pointer or a pointer to the first byte of memory.