I've realized that my understanding of ARC is not as good as I thought it was.
So I'll be asking couple of questions.
With ARC I don't understand why autorelease pools are needed anymore except for
with objects passed by reference. What I mean by that is that class methods
like:
NSString *mySt
On 16 Feb, 2014, at 9:27 pm, Kevin Meaney wrote:
> I've realized that my understanding of ARC is not as good as I thought it
> was. So I'll be asking couple of questions.
>
> With ARC I don't understand why autorelease pools are needed anymore except
> for with objects passed by reference. Wh
On Feb 16, 2014, at 7:27 AM, Kevin Meaney wrote:
> Why do these methods need to return an autoreleased object, why can't they
> behave the same as:
>
> NSString *myString = [[NSString alloc] initWithFormat:@"%@", @"my String];
>
> Is the only reason for interoperability with manual retain-rele
On Feb 16, 2014, at 5:27 AM, Kevin Meaney wrote:
> Is the only reason for interoperability with manual retain-release code?
For backward compatibility. Nearly every piece of existing Cocoa code uses
these methods, so there's no way they could take them out.
> It seems that it creates an unnec
On 16 Feb 2014, at 17:06, Jens Alfke wrote:
> On Feb 16, 2014, at 5:27 AM, Kevin Meaney wrote:
>
>> Is the only reason for interoperability with manual retain-release code?
>
> For backward compatibility. Nearly every piece of existing Cocoa code uses
> these methods, so there's no way they
On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote:
> I didn't say take them out. I said why do they need to return an autoreleased
> object. Why can't they just return an object like alloc init... does.
Because if they returned an object that wasn't autoreleased (i.e. that the
caller needs to
On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote:
> You're missing the question I was trying to ask. Why is autorelease needed at
> all?
It's needed when a method creates an object [or otherwise gets an object with a
reference that needs to be released] and has to return that object, but the
And would be just like every other manual reference-counting scheme, with all
of the additional code they entail, and the higher liklihood of bugs, and so
on...
On Feb 16, 2014, at 2:13 PM, Jens Alfke wrote:
> The only way to resolve this without autorelease would be to enforce that
> _all_ m
On Feb 16, 2014, at 1:03 PM, Jens Alfke wrote:
> On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote:
>
>> I didn't say take them out. I said why do they need to return an
>> autoreleased object. Why can't they just return an object like alloc init...
>> does.
>
> Because if they returned an obj
On Feb 16, 2014, at 10:22, Kevin Meaney wrote:
>
> On 16 Feb 2014, at 17:06, Jens Alfke wrote:
>
>> On Feb 16, 2014, at 5:27 AM, Kevin Meaney wrote:
>>
>>> Is the only reason for interoperability with manual retain-release code?
>>
>> For backward compatibility. Nearly every piece of exist
On Feb 17, 2014, at 2:08 , Clark Smith Cox III wrote:
>> I didn't say take them out. I said why do they need to return an
>> autoreleased object.
>
> Because they always have, and their semantics cannot be changed without
> breaking decades worth of non-ARC code.
Sort of like the way GC did,
Thanks to Marcel, John McCall, and Clark Smith Cox III for addressing the
question I was trying to ask, apologies to others that the question was unclear.
So it seems that because ARC provides compatibility between ARC and non-ARC
code unlike how garbage collection worked with duplicated framewo
12 matches
Mail list logo
