views:

72

answers:

2

Hey guys,

I was wondering if objective C does any check to see if a pointer to an object is nil before calling the function.

For example, say I have a

myObject* ptr;

and initialize

ptr = nil;

and call

[self myFunction:ptr];

where myFunction is my own function and does no check to see if the object is nil. I heard somewhere that objective C will not call the function if it is nil? Is this true and would my code be safe?

The reason I ask is because I'm implementing a universal app, and have an UIView instance that will only work for the ipad. But, I do many function calls for this view, and instead of doing condition checks to see if it is an ipad before calling the function, it would be great if I could set the view as nil if it's an iphone.

Also, if the interface builder allocated the object and I set the pointer to nil, will there be a memory leak or will the builder know to dealloc the object?

Thanks

+6  A: 
dreamlax
Yes, and to be extra clear to the original poster: your understanding is backwards. If the **object** is `nil`, nothing happens. If the **argument** is nil, the method is still called, and either handles nil as expected, or blows up. There's no magic around arguments.
quixoto
Thanks for the answers, guys. Yeah that answered my question. Sorry, I'm coming from procedural programming and haven't had a lot of experience with OOP, so I'm used to passing arguments and forgot about the receiver concept. Yeah, most of my code is in [myObject myFunction] format so I should be able to set myObject as nil. I'm just worried if the system passes my object around, now.
It may help if you realize that besides whatever arguments you've passed explicitly, self and _cmd are there in every method as implicit arguments. 'self' (the receiver) is just an implicit argument when your method is invoked.
NSResponder
A: 

As for the memory, if you have the object in the NIB file and then set its outlet to nil in the code, there will be a memory leak. You should release the object and then set it to nil.

It might be a good idea in that case, though, to simply create the object if it's an iPad and leave the variable as nil if it's an iPhone. That way you don't have to deal with any stray references that may crop up if you create the object in the NIB file. That may or may not be an issue, but it's probably better to create conditionally rather than destroy conditionally.

jfm429
Hmm, that's a good idea. I'll have to consider it, but I'm new to iphone programming and the interface builder is definitely a crutch for me as programming the dimensions manually might be tedious with all of the settings, especially the controls such as the segmented control and buttons. Also, the code I'm building off of uses nib files primarily.Thanks for the memory leak catch, though!
Quick question, the interface builder isn't going to try to dealloc my object after the view is done is it? Does it use release or dealloc, because if it tries to dealloc it after I release it I will have a fault error, correct?
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmNibObjects.html
jfm429
That link is valid for both Mac OS and iOS, btw, even though it's in /mac/
jfm429