Re: Looking at self = [super init].
Re: Looking at self = [super init].
- Subject: Re: Looking at self = [super init].
- From: Michael David Crawford <email@hidden>
- Date: Sat, 30 May 2015 15:08:27 -0700
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
email@hidden
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 <email@hidden> wrote:
>
>> On 30 May 2015, at 3:22 am, Alex Zavatone <email@hidden> 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 (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
_______________________________________________
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