Actually, i was typing by habit and included == instead of = by mistake.
So, while you answered the question, you may have answered the wrong question.
The question is not for
if ( self == [super init])
It's
if ( self = [super init])
How does that change your answer?
On May 30, 2015, at 6:08 PM, Michael David Crawford wrote:
> While in principle machine code implementations of subroutines can
> return from several different places, in practice they don't. Rather
> the compiler's code generator emits a branch instruction to the end of
> the subroutine, there there is an "epilog".
>
> There are many good reasons for returning from the middle in certain
> specific cases; what if the only epilog you need is an "rts"?
> Branching to the epilog could cause a cache miss.
>
> I expect the compiler developers know all about this but don't
> typically avail themselves of it because writing compilers is
> difficult.
>
> To be clear, the following source code:
>
> - (id) init
> {
> if ( self == [super init] ) return nil;
>
> // lots of code goes here
>
> return self;
> }
>
> ... is implemented as something like this, but in machine code:
>
> - (id) init
> {
> id result;
> if ( self == [super init] ){
> result = nil;
> goto epilog;
> }
>
> // lots of code goes here
> result = self;
>
> epilog:
> return result;
> }
> Michael David Crawford, Consulting Software Engineer
> mdcrawf...@gmail.com
> http://www.warplife.com/mdc/
>
> Available for Software Development in the Portland, Oregon Metropolitan
> Area.
>
>
> On Fri, May 29, 2015 at 6:25 PM, Graham Cox <graham....@bigpond.com> wrote:
>>
>>> On 30 May 2015, at 3:22 am, Alex Zavatone <z...@mac.com> wrote:
>>>
>>> // We don't care if this gets long.
>>
>>
>> My take is that you're rewriting a well-recognised idiom to solve a
>> non-existent problem.
>>
>> The well-recognised idiom makes it easy to verify it's correct. Hiding a
>> different construct inside a macro obscures that, making it harder to verify
>> the code. It's not "wrong" exactly, just harder to see at a glance that it's
>> right.
>>
>> The non-existent problem you're trying to solve is that the gap between a
>> pair of braces could get large. So what? Early returns can be another source
>> of bugs, so structural purists would tell you that you shouldn't do that.
>> Sometimes I think it's justified, but not usually worthwhile. Another
>> religious issue is whether matching braces should line up or not. Personally
>> I prefer that they do, at the cost of an extra line. Because you aren't
>> doing that, your long distance between braces is bothering you, because
>> you're losing track of where it started (I assume that's why it's bothering
>> you). If you line up the braces that is much less of an issue.
>>
>> Source code is for humans, so it should be as readable as you can possibly
>> make it. Macros often hinder that. Unaligned braces hinder that. Multiple
>> statements per line hinder that.
>>
>> Factoring code helps, so I'd suggest that's the better way to solve this.
>> (and it's also beneficial when it comes to making sure that -initWithCoder:
>> and other initializers that don't correctly follow the designated
>> initializer rule can get access to your common initialization. While this is
>> rarely a problem, I did notice that the recent change to encourage the use
>> of -initWithCoder: for unpacking NSViews from a nib breaks this
>> long-standing rule and so a common init method that both can call is a
>> simple workaround).
>>
>> --Graham
>>
>>
>>
>> _______________________________________________
>>
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
>>
>> This email sent to mdcrawf...@gmail.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:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
>
> This email sent to z...@mac.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
