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@lists.apple.com)
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
