On 30 Jan 2013, at 17:03, Quincey Morris
wrote:
> On Jan 30, 2013, at 00:42 , Charles Srstka wrote:
>
>> I *think* Xcode 4.2 was the one that introduced it, but my memory's not 100%
>> on that.
>
> Weirdly, though, in Xcode 4.6 'instancetype' is not auto completing for me.
> Is that a prob
On Jan 30, 2013, at 00:42 , Charles Srstka wrote:
> I *think* Xcode 4.2 was the one that introduced it, but my memory's not 100%
> on that.
Weirdly, though, in Xcode 4.6 'instancetype' is not auto completing for me. Is
that a problem others are experiencing?
_
On Jan 30, 2013, at 12:42 AM, Charles Srstka wrote:
> On Jan 30, 2013, at 1:25 AM, Greg Parker wrote:
>> Name the method `new...` instead of `create...`. Otherwise you do suffer an
>> autorelease penalty with ARC. (`create...` is not one of the names that ARC
>> assumes will return a retained r
On Jan 30, 2013, at 1:25 AM, Greg Parker wrote:
> Name the method `new...` instead of `create...`. Otherwise you do suffer an
> autorelease penalty with ARC. (`create...` is not one of the names that ARC
> assumes will return a retained result.)
Huh? I thought ARC generated objc_autoreleaseRet
On Jan 29, 2013, at 23:25 , Greg Parker wrote:
> Name the method `new...` instead of `create...`. Otherwise you do suffer an
> autorelease penalty with ARC. (`create...` is not one of the names that ARC
> assumes will return a retained result.)
Oops, I'm always getting that backwards. Need to
On Jan 29, 2013, at 10:25 PM, Quincey Morris
wrote:
> However, it occurs to me there's a better solution. Since we're talking about
> ARC, this pattern:
>
> + (id) createBlaWithFoo: (NSString*) foo // or the return type can be Bla* if
> you want
> {
> if (!foo)
> return nil
On Jan 29, 2013, at 20:51 , Ken Thomases wrote:
> Bob's construction is just as valid as the above because it's essentially
> doing the same thing.
The same thing, so it doesn't really adduce any further evidence (unless you
know of a documented API contract that covers this situation).
Howev
On Jan 29, 2013, at 10:51 PM, Ken Thomases wrote:
> I disagree. I think Bob's construction is valid, if unconventional. It is
> also valid-though-unconventional to release an object that you've +alloc'd
> but not -init'd at the caller side.
>
> SomeClass* foo = [SomeClass alloc];
> if (someC
On Jan 29, 2013, at 3:22 AM, Quincey Morris wrote:
> On Jan 29, 2013, at 00:51 , Bob Cromwell wrote:
>
>> if below code valid ? All sample codes I could find invoke "self = [super
>> init]" first and then check the input parameter inside "if (self)" block.
>>
>> @implementaion Bla
>>
>> -
On Jan 29, 2013, at 09:07 , Jens Alfke wrote:
> Actually this is fine, because free(NULL) is legal. A better example would be
> a dealloc that calls CFRelease, because [for some reason] CFRelease does
> crash if passed NULL.
Yes, no one is ever going to hire me for my deep Unix knowledge.
> I
On Jan 29, 2013, at 1:22 AM, Quincey Morris
wrote:
> ** Here's an example that will crash with an early return:
>
> if (self) {
> if (foo == nil)
> return nil;
> _foo = foo;
> _bar = malloc (100);
> .
> }
> …..
> - (void) dealloc {
>free (_bar);
>
On Jan 29, 2013, at 00:51 , Bob Cromwell wrote:
> if below code valid ? All sample codes I could find invoke "self = [super
> init]" first and then check the input parameter inside "if (self)" block.
>
> @implementaion Bla
>
> - (id)initWithFoo:(NSString *)foo
> {
>if (foo == nil) {
>
Hi All,
if below code valid ? All sample codes I could find invoke "self = [super
init]" first and then check the input parameter inside "if (self)" block.
@implementaion Bla
- (id)initWithFoo:(NSString *)foo
{
if (foo == nil) {
return nil;
}
self = [super init];
if
13 matches
Mail list logo
