When faced with the need to return “not found” for something that normally returns an index or other value that would normally be unsigned (whether this is an error condition or a normal event), Cocoa offers the NSNotFound constant as an alternative to returning an illegal index like -1 (which forces you to change the index to an NSInteger, raising the likelihood of sign-based errors if there’s ever a long promotion).
NSNotFound is 0x7fffffff, which is not -1 (0xffffffff), but is still very large (~2 billion) and so should never be a real index for any sanely-sized spaces, and is more readable than -1. NSNotFound is a good constant to remember when these issues come up. Look at NSString -rangeOfString: for an example of its usage.
I move between VS and XCode a bit without shuddering or fussing, which seems to make me a strange creature. In general, shocking as it is to say on a Cocoa list, VS is actually a much more powerful environment. Most who love XCode have little used VS (at least VS2005 or later, VS.NET is clunky IMO). But learning what actually is better about VS requires using XCode for quite some time. Most of the initial complaints are simply small differences between the two; many of which I prefer the XCode way. But then, XCode is a Mac app, and I generally prefer Mac UI.
Read more…
Two posts in a day… but this was a completely different topic.
I’m beginning work on my first Leopard-only application, and so I’m trying out garbage collection. Sure, I’m excited about garbage collection. Sure, I have no great love of keeping track of my retain counts and autorelease pools. But….
It feels really, really weird to not release my variables. I tend to rely on autorelease a lot. I know there are some disadvantages, but I like the fact that it notes your intention when you allocate the memory. Read more…
It’s a lazy day for me. That means I’ll probably hack stuff all day.
One of my best friends in the world just sent me a note asking for a good Cocoa reference. I thought I’d pass on the same advice I gave him:
This is the book on learning Cocoa:
Cocoa Programming for Mac OS X
by Aaron Hillegass
Third edition is supposed to come out this summer. I’ve read the proofs of the 3rd edition, and it does add some good stuff, but if you’re anxious to get started, I’d get 2nd edition and get started. Read more…
To all you aspiring Cocoa developers….
If you want to make a private framework, you need to remember to set the install path for it to @executable_path/../Frameworks. Just copying it into your bundle isn’t good enough. Otherwise your app is going to think it’s in (~)/Library/Frameworks once you package it up and give it to other people.
In related news, PandoraBoy 0.5.1a is now released.
Have I mentioned recently how much I love Cocoa? Even when I hate Cocoa, I love working in it. And things that drive me nuts (like the lack of regexes) come along in due course (Leopard). I was listening to CocoaRadio today and there was a comment along these lines. Cocoa has been evolving for about 20 years now. Much of the core is carried over from NeXT. But rather than “showing its age” it keeps showing its wisdom, and those early guys thought it out well enough that Apple hasn’t had to start over again and again as Windows has with Win32 to MFC/WTL to .NET. For how unusual Objective-C is, it’s a constant rather than moving between C, C++, C#, and Java as the winds blow. (And the more I program in Objective-C, the more I enjoy it.)
Tonight I added a station-changing menu to PandoraBoy. There’s still a lot to add to make it really useful (hotkey support and Applescript at least), but the core’s there, and it wasn’t hard. It forced me to simplify a slight duplication in the object model (PandoraControl and Controller were doing almost exactly the same work so I’ve merged them). That cleaned up a lot of redundant code. Even after merging the two objects, Controller is under 400 lines of code, so I don’t think I need to worry about splitting Controller back up some other way.
