On 14/07/2009, at 7:34 , Jeff Laing wrote:
Thus, apparentl doing
NSString *s = someobject.somevar;
is essentially against the rules. You should always use
NSString *s = [[someobject.somevar {retain|copy}] autorelease];
No, this is unnecessary. You do not need to do this unless you intend
to store it past when you return, or unless you intend to modify
(including, as you point out, release) someobject (directly or
indirectly). There is also the issue that you must be certain that
anything you call, and anything called by your callee if you return it
cannot modify/release someobject - at some point it may be easier to
use the retain/autorelease idiom than prove that nothing can modify
someobject, but often it is not necessary.
On 14/07/2009, at 8:42 , Wade Tregaskis wrote:
Whether they're cached or singletons or whatever else, they must
obey the policy that they'll stick around 'til the next flush of
the current thread's current autorelease pool. You just can't
safely handle the memory management otherwise, especially in
multithreaded cases.
My assertion there was ambiguous, it's true; I meant that you must
do so if you want to retain your sanity, not that this is what
everyone in fact does, nor has done to date. As we've seen already
through examples.
This is exactly the misconception that needs to be avoided. Here
is a trivial counter example:
id obj = [dict objectForKey:@"whatever"];
[dict release];
NSLog( @"this will crash %@", id );
No autorelease pool, no remaining valid until the current
autorelease pool is flushed.
And if you extrapolate this example further to the case where [dict
release] is called on another thread, you're in a real pickle.
Ideally, objectForKey: would retain]autorelease].
This multithreading argument is completely irrelevant. If your code
is not thread safe, that is a completely independent issue which
atomic and retain/autorelease will not solve!
Consider the case where one thread releases dict and the other thread
calls [dict objectForKey:@"whatever"] as above. Even if objectForKey
retain/autoreleas and even if objectForKey is atomic, it is
insufficient to defend you from multi threading issues. Imagine your
code is interrupted immediately on the instruction that calls
objectForKey and then the other thread that calls dict release is
executed. You still crash. Being thread safe is a whole different
can of worms and has almost nothing to do with the memory management
rules.
It is not optimising away the return [[foo retain] autorelease],
which is explicitly allowed in the rules ("That method may also
safely return the object to its invoker"), it is assuming something
about the lifetime of the object you don't own that gets people in
to trouble.
As I stated and have reiterated here, coding so defensively is just
plain bad for your mental well-being. We have to live with the
imperfect world, but the point of this is what you can do in your
code, which is to say: you can do it right, instead. Don't stress
so much over the edge cases; learn them and work around them, and
don't propagate them.
There is no need to code defensively, there is a need to code to the
rules:
<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
>
* Assume you own an object if and only if the method is named alloc/
new/copy/retain. Otherwise:
* Do *not* assume the return value is autoreleased
* Do *not* refer to the retainCount
* If you are going to store it or if you are going to modify/release
the source object, you need to take ownership of it (with alloc/new/
copy/retain).
* You can safely return it, assuming the returned code will not modify
the source object
And if you want to write thread safe code, then you need to write
thread safe code, not rely on atomic or memory management rules,
neither of which will help you appreciably.
Enjoy,
Peter.
--
Clipboard Switching and Macros with Keyboard Maestro
Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
<http://www.stairways.com/> <http://download.stairways.com/>
_______________________________________________
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
