[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] ARC and @synthesize of read only property
From:       Jean-Daniel Dupas <devlists () shadowlab ! org>
Date:       2011-07-27 18:16:43
Message-ID: CB09A342-BF46-4EA3-9F20-9B56886CFA4F () shadowlab ! org
[Download RAW message or body]


Le 27 juil. 2011 à 19:38, Argyrios Kyrtzidis a écrit :

> On Jul 20, 2011, at 3:19 AM, Jean-Daniel Dupas wrote:
> 
> > 
> > Le 20 juil. 2011 à 10:57, David Chisnall a écrit :
> > 
> > > On 19 Jul 2011, at 21:06, Jean-Daniel Dupas wrote:
> > > 
> > > > Thank you for the explanation. So the retained/autorelease is a new behavior \
> > > > introduced with ARC. AFAIK, the getter did this only for atomic properties in \
> > > > non ARC mode.
> > > 
> > > You can check the generated IR.  In ARC mode, it calls objc_getProperty() for \
> > > atomic properties.  For  nonatomic properties, it accesses the ivar directly \
> > > and calls objc_retainAutoreleaseReturnValue().  If you do something like: 
> > > id o = [object synthesizedNonatomicProperty];
> > > 
> > > Then ARC will translate this into something like:
> > > 
> > > o = objc_retainAutoreleasedReturnValue([object synthesizedNonatomicProperty]);
> > > 
> > > This skips the autorelease pool, so the object is now retained in the caller \
> > > but not present in the autorelease pool.  ARC will then objc_release() it at \
> > > the end of the scope of o.  This means that you get a lot less redundant \
> > > autorelease pool churn in ARC mode.
> > 
> > That make sense. Thanks again.
> > 
> > > 
> > > > > Even in ARC mode, the compiler can't magically guess what you mean.  
> > > > 
> > > > While it cannot always guess, when the @synthezise directive specify an ivar, \
> > > > it can default to the ivar ownership, as this is the only acceptable value.
> > > 
> > > Ivars all default to __strong, but it sounds like you actually want \
> > > unsafe_unretained (which would then simply be objc_retain()'d in the caller in \
> > > ARC mode).  
> > 
> > I really have and want a strong ivar. Declaring it as 'unsafe_unretained' will \
> > prevent its releasing in the generated object's destructor. So the solution in my \
> > case it to change the property declaration to tell the compiler it is a retained \
> > property.
> 
> This changed in r136155, now there will only be an error if the backing ivar is not \
> user declared and there is no ownership attribute on the type. 
> -Argyrios

Thank you :-)

-- Jean-Daniel





_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


[prev in list] [next in list] [prev in thread] [next in thread]