C ++中的空指针

Question

everyone, I have some question about C++, what do You actually prefer to use

int* var = 0;

if(!var)...//1)
or
if(var == 0)..//2)

what are the pros and cons? thanks in advance

Answer 1

我更喜欢if (!var) ，因为那时你不会意外地分配给var ，而你不必在0和NULL之间选择。

Answer 2

I've always been taught to use if (!var) , and it seems that all the idiomatic C(++) I've ever read follows this. This has a few nice semantics:

• There's no accidental assignment
• You're testing the existence of something (ie. if it's NULL). Hence, you can read the statement as "If var does not exist" or "If var is not set"
• Maps closely to what you'd idiomatically write if var was a boolean (bools aren't available in C, but people still mimic their use)
• Similar to the previous point, it maps closely to predicate function calls, ie. if (!isEmpty(nodeptr)) { .. }

Answer 3

Mostly personal preference. Some will advise that the first is preferred because it becomes impossible to accidentally assign instead of compare. But by that same token, if you make a habit of putting the rvalue on the left of the comparison, the compiler will catch you when you blow it:

if( 0 == var )

...which is certainly true. I simply find if( !var ) to be a little more expressive, and less typing.

They will both evaluate the same, so there's no runtime difference. The most important thing is that you pick one and stick with it . Don't mix one with the other.

Answer 4

A few years has passed...

The C++11 standard introduced nullptr to check for null pointers and it should be used as it ensure that the comparison is actually done on a pointer. So the most robust check would be to do:

if(myPtr != nullptr)

---

The problem with !var is that it's valid if var is a boolean or a numerical values (int, byte etc...) it will test if they are equal 0 or not. While if you use nullptr , you are sure that you are checking a pointer not any other type:

For example:

int valA = 0;
int *ptrA = &valA;

if(!valA) // No compile error
if(!*ptrA) // No compile error
if(!ptrA) // No compile error

if(valA != nullptr) // Compile error, valA is not a pointer
if(*ptrA != nullptr) // Compile error, *ptrA is not a pointer
if(ptrA != nullptr) // No compile error

So, it's pretty easy to make a mistake when manipulating pointer to an int as in your example, that's why nullptr should be used.

Answer 5

Either one is good, though I personally prefer 2 - or something like it.

Makes more sense to me to read:

if ( ptr != NULL )

than

if ( ptr )

The second I may confuse for just being a boolean to look at, but the first I'd be able to tell immediately that it's a pointer.

Either way, I think it's important to pick one and stick with that for consistency, though - rather than having it done in different ways throughout your product.

Answer 6

I would prefer option 3:

if(not var)
{
}

The new (well since 1998) operator keywords for C++ can make code easier to read sometimes.

Strangely enough, they seem to be very unknown. There seem to be more people who know what trigraphs are (thank you IOCCC!), than people who know what operator keywords are. Operator keywords have a similar reason to exist: they allow to program in C++ even if the keyboard does not provide all ANSII characters. But in contradiction to trigraphs, operator keywords make code more readable instead of obfuscating it.

Answer 7

According to the High Integrity C++ coding Standard Manual: for comparison between constants and variables you should put the constant on the left side to prevent an assignment instead of an equality comparison , for example:

Avoid:
if(var == 10) {...}

Prefer
if(10 == var) {...}

Particularly in your case I prefer if(0 == var) because it is clear that you are comparing the pointer to be null (0). Because the ! operator can be overloaded then it could have other meanings depending on what your pointer is pointing to: if( !(*var) ) {...} .

Answer 8

1. DON'T use NULL, use 0.
2. Strictly speaking, pointer is not bool, so use '==' and '!=' operators.
3. NEVER use 'if ( ptr == 0 )', use 'if ( 0 == ptr )' instead.
4. DON'T use C-pointers, use smart_ptr instead. :-)