Re: ObjC in time-critical parts of the code
Re: ObjC in time-critical parts of the code
- Subject: Re: ObjC in time-critical parts of the code
- From: Jean-Daniel Dupas <email@hidden>
- Date: Mon, 19 Jan 2009 01:06:13 +0100
Le 19 janv. 09 à 00:56, Justin Carlson a écrit :
John Engelhart wrote:
> On Sat, Jan 17, 2009 at 7:44 PM, Scott Ribe <email@hidden> wrote:
> >> TBH (and more to the point) I strongly suspect it's true of
everyone
> >> who's expressed an opinion in this thread that it's not so much
about
> >> the suitability of the language to optimizations, but more
about the
> >> skill set of the individual with regard to the language.
> >
> > Well, there is a degree of efficiency that can be had with C++
classes that
> > simply cannot be had with Objective-C classes.
>
> You keep mentioning this, but I don't recall seeing an example of
this
> 'inefficiency' you keep referring to. If I were to take a guess at
> it, I'd venture that it's along the lines of "accessing a variable
of
> a struct/class", or something along the lines of:
That is one good example, but there is *much* more to it.
> Of course, that's just one way to do it. The ObjC language doesn't
> require that you write getters and setters to access an instances
> ivars, that's just good OO programming style. But since you're
> talking about "optimized performance" code then I think "knowing
when
> to bend the rules" is perfectly fair game, as long as you understand
> the consequences. The ObjC example above can then be rewritten as:
> [code]
> This translates exactly in to the same instructions as the "pure,
raw
> C" version. You obviously loose the flexibility of the ObjC OO
> getter/setter way, but you're in control of that trade-off. This
is a
> completely acceptable "bending of the rules" when doing performance
> optimization and the need for performance outweighs the loss of
> functionality or extra complexity elsewhere to compensate for the
> performance special case.
An additional problem is that it does not scale well. Programs
mature, objects are used beyond their initial intent, programmers
come and go and that source becomes a nightmare to maintain. Getting
back to good OO style, why take the messaging overhead (how often do
your subclasses rewrite getters/setters?)
Each time you use KVC/KVO.
_______________________________________________
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