Re: NSPoint and automatic constructor
Re: NSPoint and automatic constructor
- Subject: Re: NSPoint and automatic constructor
- From: Allan Odgaard <email@hidden>
- Date: Mon, 24 May 2004 04:04:49 +0200
On 23. May 2004, at 2:46, Jim Witte wrote:
What exactly *is* an automatic constructor (I'm continually learning
that I really don't know C++ much at all - I know enough of it that
Java was simple, but not much more) I can see a constructor, which
would allocate a structure and then return it's pointer, but in an
example like the one cited:
Implicit/automatic constructor is not a defined term AFAIK, just what
we call a currently non-existing feature.
In C++ you can write:
struct Point
{
float x, y;
Point (float x, float y) : x(x), y(y) { }
};
This shows an explicit constructor, i.e. I had to type the code myself
(the same as for Java). I can then write "new Point(3, 4)" to get a
point. Had I not typed the constructor, that would *not* have been
possible (and that is what people were requesting).
But I could do (w/o the explicit constructor):
Point p = { 3, 4 };
Or (in C99):
(Point){ 3, 4 };
This is just standard field-by-field initialization.
NSMakeLine( NSPoint(x,y), NSPoint(q,r) )
there are no variables to assign the NSPoints to..
In Java there is only heap storage, and you allocate from it using
'new' and thus get a pointer to somewhere in the heap.
C/C++ also has automatic storage, generally this is just the stack. So
if you do not write 'new', the object is placed on the stack (and will
be destroyed when you go out of scope).
So we can either write (pointer to heap):
Point* p = new Point(3, 4);
...
delete p;
Or (instance on the stack):
Point p = Point(3, 4);
...
And the point is destroyed when we go out of scope, since the storage
for the point is "automatic". This is similar to when we use it in a
function-call, e.g.:
MakeLine(Point(3, 4), Point(5, 6));
Two temporary objects (one for each point) are created on the stack and
will be destroyed when leaving the scope in which they were created.
This is one reason why C/C++ is often much faster than garbage
collected languages, because stack allocation/de-allocation is
practically free (the compiler adjusts the stack pointer in the
beginning of the function to account for the space required by the
function entered, and then sets it back when leaving the function) and
there is also a strong locality of reference (i.e. most "active" data
is probably on the stack, and within the same frame).
_______________________________________________
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.