tags:

views:

111

answers:

3

Hi, I'm building a iphone app and using c++ and am having trouble checking if a pointer is null.

IMyInterface* myInterface;

if ( !myInterface ){                         //doesn't work
     myInterfacee->doSometing(); 
}

if ( myInterface != 0 ) {                    //doesn't work 
     myInterfacee->doSometing(); 
}

if ( myInterface != NULL ){                  //doesn't work
     myInterfacee->doSometing(); 
}

if ( myInterface != ( myInterface* )0 ) {    //doesn't work 
     myInterfacee->doSometing(); 
}

If myInterface is or isn't set it still enters each statement and gives me

Program received signal: “EXC_BAD_ACCESS”.

How do i go about checking if myInterface is null

+3  A: 

Your problem is that pointers are not automatically initialized to NULL by default. All of the methods you have there should work, but you'll need to initialize your variable to be NULL when you define it.

nonVirtualThunk
+6  A: 

You do not initialize myInterface, so its value is indeterminate. You need to initialize it to null:

IMyInterface* myInterface = 0;

Or, if you can, it is usually preferable to initialize the variable to a valid state when you declare it:

IMyInterface* myInterface = new TypeImplementingInterface();

You should also consider using smart pointers of some kind, like shared_ptr; smart pointers make memory management in C++ far simpler.

James McNellis
Awesome, thats what i was looking for. Thank you.
+14  A: 

Your basic problem here is that you haven't initialized myInterface.

Assuming myInterfacee is just a typo, the following would all be fine, and none of them would call doSometing:

IMyInterface* myInterface = 0;

if ( myInterface ){                // ! removed
     myInterface->doSometing(); 
}

if ( myInterface != 0 ) {          // as before
     myInterface->doSometing(); 
}

if ( myInterface != NULL ){        // as before
    myInterface->doSometing(); 
}

if ( myInterface != ( IMyInterface* )0 ) { // IMyInterface, not myInterface
     myInterface->doSometing(); 
}

Personally, I prefer the first two over the third, and don't like the fourth at all, but that's a question of style rather than correctness.

If myInterface is or isn't set it still enters each statement

I sort of disbelieve this, but if that's really the case (you're initializing myInterface, and still seeing that both the if (!myInterface) and the if (myInterface != 0) clauses are executed), then there is something very wrong elsewhere in your program. Those tests have opposite meanings, so the only way they're both going to appear true is when something undefined is going on.

Steve Jessop
Good catch on the `!`!
James McNellis
I think most people would agree that the 4th form should not be used (it's pointless and hinders readability), but the choice between the first 3 is purely a matter of style.
Adam Rosenfield
What's your opinion on using nullptr (when C++Ox rolls into town)?
Martin York
@Martin: it's better than `NULL`, but I don't think it's *enough* better than `NULL` for me to bother using `NULL` now so that I can find-and-replace later. AFAIK, the benefit it has over `0` is that using it in the RHS of an assignment, initialisation, or comparison acts as a bonus "static_assert(lhs is a pointer or bool)". I might eventually find that useful, and I've no objection to it. Literals in C++ always have been, and will remain, very weakly typed in general. I've learned to live with that, so this one small strengthening doesn't excite me. I also don't write `'\0'` for ASCII NUL.
Steve Jessop
In assignments and comparisons, that is. It's good to use correctly-typed literals as function arguments, just in case there's overloading or type deduction going on. I expect I'll make a habit of using `nullptr` when calling functions that take a pointer but allow null, like `snprintf`. Not that I frequently find myself calling `snprintf` in C++, (and not that I expect it to be overloaded, just an example of the type). That habit might lead me to start using `nullptr` everywhere else too.
Steve Jessop
The first form works with pointer-like objects that supply an inexpensive coersion to `bool`. The other forms would require the pointer-like object to coerce to an actual pointer for comparison which is potentially more expensive than the simple existance test implied by the first form. I strongly prefer the first form.
RBerteig