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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
