Convenience #DEFINEs

Update: Lazy programmer, indeed! After doing some research myself this afternoon (at the prompting of Karsten), I’d recommend not using anything but the ZNCGAutoRelease() method below — the others aren’t dangerous, but they’re really not necessary and just obscure your ability to properly debug your code. As for using macros, well, I guess that’s a matter of personal preference — what I’ve seen so far is that it does make debugging harder — you’re probably better off implementing proper methods for repeatable tasks. But it works if you want to use it.

When I first started working on VirtueDesktops (all those years ago), I was still new to Objective-C and very new to the concept of (mostly) manual memory management. Thankfully Thomas (the previous developer) had the foresight to do what all good, lazy programmers should do and write himself a few small convenience methods into his codebase.

They’ve had a couple of minor additions and changes since then, but line-for-line, they’ve stood the test of time and I find them an invaluable way to reduce some of the fuss involved in manually managing your object assignments, copies and releases.

#define ZNCGAutoRelease(x) (__typeof(x))[NSMakeCollectable(x) autorelease]

#define ZNAssign(aTarget, aSource)  \
if (aTarget != nil) {               \
    [aTarget autorelease];          \
}                                   \
aTarget = [aSource retain];

#define ZNAssignCopy(aTarget, aSource)  \
if (aTarget != nil) {                   \
    [aTarget autorelease];              \
}                                       \
aTarget = [aSource copy];

#define ZNRelease(aTarget)          \
if (aTarget != nil) {               \
    id oldObject = aTarget;     \
    aTarget = nil;                  \
    [oldObject release];            \
}

I use these everywhere in my code, but just the other day I discovered the absolutely incredibly wonderful CLANG Static Analysis tools (more on this shortly!), and based on some feedback it gave around these calls (nothing bad!) it made me wonder — should I be #DEFINEing convenience methods? Is this best practice? Should I go back to doing this all by hand?

I’m hoping some of my CocoaPeers™ will be able to provide me with some advice here, but if you think the code’s good for your needs — go for your life and use it.

Oh, and happy 4^th of July to our friends in the states. We’re waiting for you here on the 5^th :)

∞

Posted: July 5, 2008 at 13:00

Tagged: Cocoa, Programming

Comments

you don’t need to do all those nil checks. Unlike in Smalltalk, you can send messages to nil in Objective-C. If a message is sent to nil, nothing happens. You should read this post about Nil over at rediculousfish.com: <http://ridiculousfish.com/blog/archives/2005/05/29/nil/> there’re plenty of other highly interesting posts there about Objective-C in general.
Anyway, in general I’d avoid using Macro Functions. The compiler already optimizes the hell out of your code. Macro Functions are also unnessesarily hard to debug and prone to errors. If you do want to use such snippets, using them as c-functions should do :-)
just my two cents… Kind Regards Karsten

Posted by Karsten on July 5, 2008 at 16:10

Thanks Karsten — that’s exactly the sort of feedback I was looking for!
The main reason for ZNRelease() is that I often deal with CoreFoundation objects — ZNRelease() just means I use the same release statement for both types (which is lazy, I know!). Does this still count as valid?

Posted by Tony Arnold on July 5, 2008 at 16:14

I think your use of macros in this case is okay. The reason being is that not repeating yourself is generally a good thing, and I think that using these macros will generally reduce the number of errors in your code. Memory management errors are typically fairly severe when they occur, and thus avoiding them (i.e. segfaults, etc) is good.
Being systematic and reducing code complexity is generally a good thing, and that is what these macros are helping with. The only thing you would be doing by removing these macros and replacing them with code, is adding many more lines of boiler plate memory management and many places for typos and errors to creep in.

Posted by Samuel Williams on July 7, 2008 at 15:41

After a little more research, it looks like you can’t send release to nil (which I’d always assumed). This makes ZNRelease() a little more interesting, but still a macro. I’m going to try doing this all by hand for now.

Posted by Tony Arnold on July 7, 2008 at 21:26

Sorry, this conversation has finished.

This post is a bit old now, so I've closed the conversation. If you're keen to keep talking about it, please email me directly.