Subject: Re: Memory allocation pattern related question



On Mar 29, 2009, at 8:35 AM, Daniel Luis dos Santos wrote:

I have a shared library and some client code. In the shared library I am adopting the following method signature pattern :

- (int) someMethod: (aType*)someInParam anotherParam: (aType**)someOutParam;

I use the return value to indicate success or failure in the execution of the method, and the arguments to pass parameters in and out.
The out parameters are double pointers.

Also, the pattern I am using mandates that the out parameters dereferenced values are allocated within the method. So :

- (int) someMethod: (aType*)someInParam anotherParam: (aType**)someOutParam {

*aType = [[aType alloc] init];

I assume you meant: *someOutParam = ...


return 0;
}

would do some logic and allocate the return value and set it to the double pointer, that would be the visible on the calling scope.

My problem is that I am not really sure of the way Cocoa retains and releases objects.

Then you should review the memory management guide for Cocoa:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/

It addresses this issue directly. Search for "Objects Returned by Reference" in the "Object Ownership and Disposal" article. (Well, review the whole document.)


Using a global auto release-pool, when is the out param object released ? At the end of the scope of someMethod ? or when I explicitly release it?

The above questions demonstrate confusion about the nature of autorelease pools. First, in the code snippet you provided, you haven't autoreleased anything. So, the behavior of autorelease pools don't enter into it. However, if you had autoreleased the object you allocated, then it would receive a -release message when the autorelease pool is drained. Draining an autorelease pool is something done explicitly by whatever code created the pool. If you haven't created a pool in your own code, then you aren't managing when it is drained, so you have no certainty about when it will be drained. Since you're relying on the framework to manage an autorelease pool, then at least you can be sure it won't be drained until you return out of your methods back to a point where the framework called your code.

It is _not_ the case that autorelease pools are automatically invoked just because execution has left a scope. This is not like C++ destructors for stack-based variables.

If the former, I have to retain it withing some method so that when its scope finishes the ref count doesn't go to zero right ?

Again, with reference to the code snippet you provided, you have allocated an object. This leaves you with ownership of a responsibility for, at some point, releasing that object. Your code does not currently deal with that responsibility, meaning the object won't ever be deallocated because it hasn't been fully released. Retaining it further will only compound this problem.

You should generally get away from trying to think about reference counts, because it will just mislead and confuse you. Think about your responsibilities. Handle your responsibilities (and only those) and don't try to think about anything else.


Since the idea is to continue using the return type throughout the enclosing method call's scope how do I implement this safely so that I don't end up trying to access release memory ?

You would have someMethod:anotherParam: autorelease the object it allocates, so it conforms to the memory management conventions. Your method someMethod:anotherParam: has allocated the object, so it has the responsibility for making sure that it is eventually released. Since you want to pass the object out to the caller, you don't want to -release it directly during the call. Using -autorelease allows you to both meet your responsibility and also allow the object to remain "live" for the duration of the calling function.

Regards,
Ken

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/maillists%40codeha.us

This email sent to maillists@xxxxxxxxx



Privacy