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: Mon, 01 Jun 2015 17:01:04 -0700
Steve - are you saying that C++ destructors aren't called if you use a goto?
It was my understanding that the destructor is called if you go out of
scope for any reason, even if it's a goto.
Michael David Crawford, Consulting Software Engineer
email@hidden
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Mon, Jun 1, 2015 at 4:39 PM, Quincey Morris
<email@hidden> wrote:
> On Jun 1, 2015, at 14:52 , Britt Durbrow <email@hidden> wrote:
>>
>> I happen to like an extra semicolon after a closing brace when it's the end of the logical block. It's just the way I like it to look (it feels 'funny' to me to have a statement end without one); the compiler ignores it. YMMV.
>
> The issue here is that you may find it comforting to see ';' at the "end" of a statement, but it skates right over the ambiguity of when a "{ ... }" construct is to be regard as a "logical block". The compiler does *not* ignore the ";" after "}". The following does *not* compile:
>
> if (...) {...}; else {...};
>
> You can argue that the intermediate ';' not the end of a logical block, but if a "}" isn't the end of a logical block, you've just changed a stylistic rule into a syntax rule.
>
>> I don't use underscores to prefix ivars. I think it's ugly, and unnecessary -- it doesn't help with namespacing (if a subclass and a superclass both declare _someVariable with the underscore they will collide just as badly as if they declare someVariable without one)
>
> The real reason for this convention is something else. In the bad old days (meaning, more or less, pre-Leopard), there were multiple conflicting conventions about using "_" for naming. Perhaps it was when the clang compiler was introduced, I can't remember exactly, but Apple decreed the current convention, to work around the inherent unsafety of Obj-C namespacing:
>
> -- Private 3rd party instance variables *should* use the underscore.
>
> -- Private 3rd party methods *must not* use the underscore.
>
> It's not really a question of good or bad. It's more a question of what we were required to do to avoid future Cocoa frameworks releases from retroactively breaking our apps.
>
> On Jun 1, 2015, at 15:14 , Charles Srstka <email@hidden> wrote:
>>
>> Which is not at all, actually:
>
> The answer is "not at all" only with the modern ABI. 32-bit Mac compilations will conflict.
>
>
>
> _______________________________________________
>
> 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