I\'m inclined to write if statements by using logical negation operator:
if (!p)
some_code();
Some people around me tend to use explicit co
If the language is C and if p is a pointer then if (p) and if (!p) should be avoided.
C (the language) doesn't specify that the null pointer will be boolean false. It does say that 0 casted to a pointer (either implicitly or explicitly) will give the null pointer.
Therefore testing p rather than p == NULL are not necessarily the same, and on some older hardware they are definitely not the same since the null pointer is actually a pointer to a particular memory page.
You can however guarantee that 0 and therefore NULL are equal to the null pointer, because C says they must be.
To contrast @Erik's answer I would say use !
for readability. If you find you are overlooking it then get your eyes tested. What's next? Avoid 1, use 3 - 2 instead?
Personally, I'm a bit bored of the implicit conversion from int to boolean. I don't think it adds much to the C language any more. In C89 where there's no boolean type it's perfectly reasonable to use an integer as a boolean, in which case the conversion leads to good-looking code. I see why it can't be removed, especially when dealing with libraries that for compatibility reasons can't be changed to return boolean now there is one. But I certainly don't think it should be used in all cases.
Sometimes, a 0 integer value means "there isn't one", but sometimes it means "there is one and it's zero". So I'm happy with:
users = get_number_of_users();
if (users) {
// there are users
...
} else {
// there aren't users
}
I'm not at all keen on:
length = strlen(ptr);
if (length) {
// there is length? OK, sort of...
} else {
// there isn't length? No, wait, there *is* a length, that length is 0
}
So there's your pragmatic reason to write if (length == 0)
in preference to if (!length)
. "If not length" makes no sense in English, so isn't necessarily what you should be writing in code either.
Admittedly, 0
was invented as a special place-holder to mean "there aren't any". But the realization that in many contexts it could be treated as a number like any other was an important breakthrough in the history of mathematics, and I don't think we should discard that just because C provides us with a syntax to treat it specially again ;-) If you want to know whether a number is 5, you compare it with 5, and normally I think the same should hold for 0.
Some claim that the pragmatic benefit is that programmers will find it easier to understand if you explicitly compare against NULL, FALSE, 0, etc., whereas the logical operator may be confusing to people who don't understand how implicit conversions and booleans work in C/C++.
(Disclaimer: I don't share this view myself. if (p) ...
and if (!p)...
are the idiomatic ways to express this in C and C++, and programmers who have trouble understanding them have no business touching C or C++ code. Heath Hunnicutt's comment is dead on.)
One as-yet-unmentioned benefit to the if (!Foo)
version is that it will work with classes that used the safe bool idiom. In classes that implement that, comparison operators of classes will fail (e.g. Foo==0
will be undefined) but !Foo
will call a conversion operator on Foo, returning a pointer to member function (or null pointer, if Foo
should be treated as false). A number of Boost classes, like shared_ptr, use this technique.
Use (0 == p)
or (p == 0)
for readability. That !
is easier to overlook at first glance than == 0
Use (0 == p)
if you have a habit of ignoring compiler warnings, and want to know when you use = rather than ==.