Random Objective-C Question

Just a quick question for any of you Objective-C programmers out there:

How do you determine if a pointer hasn't been allocated to an object?

For example, say I had the following declaration:

NSAttributedString	*attribString

I have coded a few If statements that *may* point that pointer to a new NSAttributedString object, but how would I be able to test if this pointer has actually been "pointed"? :P

I originally thought it would be something like:

if(attribString)

but that returns true no matter what, and so does

if(attribString!=NULL)

and

if(attribString!=Nil)

and

if(attribString!=nil)

It returns true in every case!


Anyone any ideas?

I've only just started on Obj-C but I got the impression that the initial declaration has to be something like:

NSAttributedString *attribString = [NSAttributedString alloc];

So if you're not initially pointing the declaration at a new object instance can you not go...

NSAttributedString *attribString = Nil;

...to make sure that it returns Null until you allocate a new instance to it?

Yep, that was my workaround - but I couldn't help wondering what it was pointing to by default...

Thanks for your response!

Hi,

In c/c++/objectiveC, any uninitialized variables are just that - they contain 'random' data depending on what was in memory at the time.

Uninitialized pointers are extremely dangerous and a very common cause of 'segfault' type bugs.

Eeeeekkkk! Didn't know that - am currently wrestling around with the beast that is cocoa.macos.m so this will be really useful to know.

Ooh, one other thing - I found out that because of the ultra-slick messaging syntax in Objective-C, it isn't compulsary to cast objects down to a lower descendent to call a method/selector that isn't in the parent class - it automagically finds and calls it. ;-)

But for some strange reason, there are a lot of places in cocoa.macos.m that handle each gadget separately and cast the gadget into the corresponding type before calling the exact same selector/method. This results in heaps of switch blocks which can often be replaced by casting as the common parent class, and using that to call the same method/selector anyway. Providing I know 100% that all the objects can respond to that selector (even if I didn't, I could check with the respondsToSelector call), is there any disadvantage to doing it this way? It seems to make for cleaner code and after a few days of testing, I haven't noticed any changes in any of my MaxGUI test program suite. ;-)

It's not necessary, but often prevents compiler warnings of the nature 'object may not respond to selector blah'.

And using (sometype*) to cast pointers in c/c++/objc doesn't incur any overhead (ie: it doesn't generate code), it's really just a way to telling the compiler that you (think you) know what you're doing.


I'd recommend caution here: "initWithBytes:length:" and "initWithBytes:size:" are not the same selector, and I'm not 100% sure how objc even handles different param types (eg: ints vs floats) and how this affects selector selection(!).

But feel free to experiment anyway!

OK, fair enough. Well I haven't gone over the top with my streamlining, just when I felt nothing was added by casting. No compiler warnings yet, so looks like I'm doing OK.


Yep, gotcha! Wikipedia had a really useful article on Objective-C, and there are quite a few other good tutorials on the net, so I spotted this potentially hazardous behaviour before I started hacking (thankfully).

Just sent my MaxGUI changes out for testing, so hopefully I'll have a pile of updates to checkout by the end of the week (that is, if my BETA testing team don't find anything to report). ;-)