Re: Properties, Attributes and Retain+Autorelease
Re: Properties, Attributes and Retain+Autorelease
- Subject: Re: Properties, Attributes and Retain+Autorelease
- From: Fritz Anderson <email@hidden>
- Date: Wed, 29 Jun 2011 06:58:35 -0500
On 29 Jun 2011, at 5:53 AM, Markus Hanauska wrote:
> The code above already reveals a huge problem: When I read the terms "atomic" and "nonatomic", I certainly expect one to use a lock (or at least atomic operations of some kind) and the other one not. This is no big surprise. What is a big surprise though, is the fact that one version extends the lifetime of an object beyond the lifetime of its "owner", while the other one won't. This has *NOTHING* to do with wether an operation is atomic or not!
>
> E.g. consider the following code:
>
> ObjectCreator oc = [[ObjectCreator alloc] init];
> id value = [oc value];
> [oc release];
> [value someMethod];
>
> In case a) this will work just fine, however in case b) this code might *CRASH* my app! This is a fact not obvious to many developers. The nonatomic attribute makes getters behave like "getters" of NSArray or NSDictionary, which do not extend lifetime of returned objects beyond their own lifetime, while normal, atomic getters do the "retain+autorelease dance". This is something that should be written on the very top of Apple's doc in bold letters with a font size of 18 pt.
>
> Unfortunately a) and b) are the only obvious cases, already c) and d) are not really explained in detail. One thing that seems obvious is c) and d) use "copy" instead of "retain" in their setters. However, what about "getters"? Do they use "copy" there as well? Do they use retain+autorelease? Do they just return the values? Are the getters equal to the getters a) and b) for "copy" properties?
>
> Similar questions arise for e) and f). E.g. will e) return the values retain+autorelease, even though the setters don't use retain? And how does nonatomic make any difference for "assign" properties? "Assigning" a pointer is guaranteed to be atomic anyway by the complier, at least for 32 bit pointers on i386 architecture when using GCC. I guess the same holds true for 64 bit pointers on x86_64 architecture (so I had to re-read the GCC specification to ensure that fact). Is the nonatomic attribute ignored for "assign" properties?
>
> These open questions are what drives me away of using properties, since when I write my getter/setters myself, I know at least the answers to all those questions and the answers will not change either (contrary to the answers for properties, that might change whenever Apple releases a new Objective-C language specification).
Your conjectured implementations are just that — conjecture. Apple may be (and probably is) using methods more primitive than retain/release/autorelease. It may (probably has, and very probably will) change the implementation between point releases of the operating system.
Your confusions and speculations become moot when you follow the rules: If you want to keep something, retain it. That covers all the code you suppose Apple wrote, as well as all the code Apple did write.
My instincts, too, rebel at "value," in your example, going away. I'd like objects to behave like scalar values, or like C++ local objects. They don't. The memory-management rules say they don't. I myself cheat, but even I don't expect an object to survive the explicit destruction of its container.
— F
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden