convenience #defines / entries / tonyarnold.com

Entry

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 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 4th of July to our friends in the states. We’re waiting for you here on the 5th :)

Total Number of Words: 336

4 Comments

Karsten 5 Jul 08 at 5:10pm

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

Tony Arnold 5 Jul 08 at 5:14pm

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?

Samuel Williams 7 Jul 08 at 4:41pm

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.

Tony Arnold 7 Jul 08 at 10:26pm

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.

Comment Guidelines

Include no more than 4 links, otherwise your comment will be flagged as spam.
Links are automagically generated for you.
<em>text</em> to make text italic.
<strong>text</strong> to make text bold.

tonyarnold.com

Entry

Convenience #DEFINEs

4 Comments

Post a comment

Comment Guidelines