Re: NSPoint. The results. Look at that, Georg!
Re: NSPoint. The results. Look at that, Georg!
- Subject: Re: NSPoint. The results. Look at that, Georg!
- From: Simon Stapleton <email@hidden>
- Date: Mon, 3 Mar 2003 20:46:17 +0100
Sherm Pendley <email@hidden> wrote:
On Monday, March 3, 2003, at 08:23 AM, Pascal Goguey wrote:
I made all the experiments in C++
Which, unfortunately for the rest of your argument, makes them
completely invalid with respect to Objective-C.
Ummmm. Largely, yes.
An Objective-C message
and a C++ method, while similar in concept, are *completely* different
in implementation.
Yes. Indeed.
<snip description of differences between ObjC and C++ method invocation>
It is indeed true that ObjC messaging is slower than C++ method calling
- however, and as ever, one can optimise out a lot, if not all, of the
overhead from the ObjC runtime (after some careful profiling). I
wouldn't be too worried about this overhead at first - wait and see if
it's a problem first...
In C++, the space of an object is not bigger if it is a class rather
than if it is a structure.
That's hardly a surprise, since an instance of a class is basically
just
the struct that holds its instance variables.
And in ObjC, it's what? A struct that contains its instance variables,
along with an ISA pointer that points to its class. No big overhead
there. In fact, I'd be surprised to find that the C++ representation
is, overall, _any_ more efficient than that used by ObjC (but I'm quite
possibly wrong)
Unfortunately, comparing the size of a single instance doesn't take
into
account the space (or time) used by the additional methods needed to
access an object's instance variables. If you're using a struct, you
can
get a point's X coordinate with a simple myPoint.x; if it were an
object, you'd need to implement a getX() method. That method will *not*
take zero bytes,
Yes, but it will only exist once per class, not once per instance.
This stands true for both C++ and ObjC. And it won't take much more
space than the code you have to write anyway. Plus, it encapsulates
the object. If you change the underlying representation of the point,
you don't need to change 3/4 of your code. But you knew that.
and it most certainly will not execute as quickly as
direct access to the struct member x.
True, but again, one should only optimise when one needs to. NSPoint
has _already_ been optimised down to a struct, which is great for doing
specific 2-dimensional stuff in a hurry, but not necessarily terribly
useful if you're doing computational geometry, for example - a
2-dimensional point that uses inaccurate representation is far from
complete...
On top of that, if you're in a real hurry, you can always get access to
the guts of an ObjC instance (see the ObjectiveC documentation on your
hard disk for details). It's not generally a good idea (encapsulation
being a _very_ _good_ _thing_), but no worse than direct access to a
struct (which is what it boils down to anyway).
why are some NS objects only structures while others are classes?
Why are many simple variable types - int, float, BOOL, pointers -
declared as such? Because OOP, like many things that can be beneficial
when taken in moderation, can be harmful when taken to absurd lengths.
Not everything *needs* to be an object.
True. But necessity changes dependent on the application. You quote
int, float, BOOL above, but we also have NSNumber, do we not?
As an example, I have an application for powerkite design. It deals
with a fairly large number of curves (tens of thousands) per model,
each of which is mutable and having 3 dimensions which need to be
accurately represented (floats don't cut the mustard here).
The design of this started off with a 'point' class, which got wrapped
up in a 'curve' class, etc etc. It soon became apparent, however, that
this was rather inefficient, and after some heavy profiling and
refactoring, I have a 'curve' class which is almost entirely
independant of the point class. It can be queried for individual
points, which can then be used to mutate the curve, but the math and
representation is all wrapped up in the curve class, which has suddenly
become a very generalised and highly efficient single class, as opposed
to a cluster with a lot of nasty 'gotchas'. In fact, in my case, the
point class is only used as a gateway between the accurate
3-dimensional representation generated by the curve and the inaccurate
2-dimensional representation used in NSPoint, and only exists for the
lifetime of the mutation operation. I still need the point class,
though. It serves me well.
On the other hand, I do entirely agree with the "don't make everything
a class" standpoint. It's just that, in this _particular_ case, there
are a large number of applications which might have a need for a point
class as opposed to a struct. On the other hand, you don't necessarily
need to roll (all of) your own - for example, for computational
geometry there are a number of rather handy C/C++ libraries that can be
used (CGAL springs to mind here).
Some possibly relevant resources are:
General math/science stuff and libraries:
http://www.mathtools.net
http://sal.kachinatech.org (IIRC)
Good design patterns:
http://www.c2.com/cgi/wiki?PortlandPatternRepository
Simon
--
PGP Key Id : 0x50D0698D
--
If the answer isn't obvious, the question is a distraction. Go find an
easier question.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.