Comments on: Don’t pass objects as context pointers

By: BJ Homer

BJ Homer — Thu, 07 May 2009 02:51:42 +0000

Nevermind that; it ends up being pretty much the same solution you already suggested. You could just as easily pass the ivar in the context pointer; the sheet already has access to self by virtue of being a delegate.

By: BJ Homer

BJ Homer — Thu, 07 May 2009 02:44:57 +0000

What if you created an instance variable in self to store the object and then pass self in the context pointer? The sheet can access the object through the context pointer, but doesn't need to retain it. It's a weak pointer, and if self goes away, the object isn't leaked. In this case, the context pointer really does become more of a context pointer.

By: Peter Hosey

Peter Hosey — Mon, 06 Apr 2009 15:24:57 +0000

Petteri Kamppuri: Yes, since -retain and -release are no-ops. This doesn't solve the problem that you're putting an object through the context pointer in the first place; all it is is retaining and releasing it in a different way. As I said in the post, everything I said there applies just as much with GC as without it. I disagree with Apple's statement that “The solution is to use a CFRetain/CFRelease pair as the value is put into/taken out of the void * parameter.” The solution is to hold your own strong reference to the object.

By: Petteri Kamppuri

Petteri Kamppuri — Mon, 06 Apr 2009 07:07:02 +0000

It seems that Apple recommends the CFRetain/CFRelease solution, at least in a GC environment.

http://developer.apple.com/documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcUsing.html#//apple_ref/doc/uid/TP40008006-SW4

By: Peter Hosey

Peter Hosey — Sat, 04 Apr 2009 02:09:47 +0000

Chuck: In this very post, I noted not one but two cases in which you leak the context object.

By: Chuck

Chuck — Fri, 03 Apr 2009 22:29:00 +0000

This strikes me as unnecessarily introducing more code. As this pattern is normally used, I can’t figure out what would lead to a memory leak. What is the situation where we gain any benefit except warm fuzzies from introducing ivars and setters and what-have-you?

By: Peter Hosey

Peter Hosey — Fri, 03 Apr 2009 20:02:27 +0000

Jeff Johnson: Yeah, I saw that, too. Shouldn’t be a problem as long as you only extend and not override.

By: Jeff Johnson

Jeff Johnson — Fri, 03 Apr 2009 19:40:21 +0000

Peter, you’re right, it appears not to be documented whether you can use endSheet: in that case. I’ll see if I can find an example somewhere.

I did notice this in the documentation, however: “The NSAlert class is not designed for subclassing.”

By: Peter Hosey

Peter Hosey — Fri, 03 Apr 2009 18:04:29 +0000

Vincent Gable: If you’re certain that there’s no memory leak, then you can use the context pointer. But you’re right that it’s dubious even for non-objects—consider the case of something you’ve mallocked, for example.

Jeff Johnson: Hm. I’m not sure it’s OK to pass NSAlert’s window to endSheet:returnCode:. The documentation doesn’t say it is; all it says definitely is that you shouldn’t use orderOut: on the window from outside the did-end method.

By: Jeff Johnson

Jeff Johnson — Fri, 03 Apr 2009 17:46:01 +0000

I’m not sure I understand point 3. Let’s talk about NSAlert, because you really shouldn’t be using NSBeginAlertSheet() anymore. ;-) If you called -[NSAlert beginSheetModalForWindow:modalDelegate:didEndSelector:contextInfo:], and you’re about to be deallocated, you should call -[NSApplication endSheet:returnCode:], in which case the didEndSelector is called.

By: Vincent Gable

Vincent Gable — Fri, 03 Apr 2009 17:37:06 +0000

By the same reasoning, is passing anything, not just objects, to the context-pointer a bad idea, or are there cases where it’s not a dirty thing to do?