Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- Subject: Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- From: glenn andreas <email@hidden>
- Date: Wed, 6 Feb 2008 21:01:45 -0600
On Feb 6, 2008, at 7:48 PM, John Engelhart wrote:
int main(int argc, char **argv) {
NSObject *stackObject = NULL;
stackObject = alloca(sizeof(stackObject));
This, of course, just alloced something the size of a pointer, which
may not be the real size of the class (if it were something other than
NSObject)
memset(stackObject, 0, sizeof(NSObject));
stackObject->isa = [NSObject class];
NSLog(@"stackObject: %@", stackObject);
}
[johne@LAPTOP_10_5] /tmp% gcc -framework Foundation -o tst tst.m
tst.m: In function 'main':
tst.m:7: warning: instance variable 'isa' is @protected; this will
be a hard error in the future
[johne@LAPTOP_10_5] /tmp% ./tst
2008-02-06 20:17:16.306 tst[18320:807] stackObject: <NSObject:
0xbffff380>
As the address clearly shows, this is an object on the stack.
Although I have had to manually initialize the object, it is
exactly, or very close to, what "NSObject stackObject" would have
created.
The biggest problem is that the above example shows something that
isn't usable - it's sterile. You can't pass it to other routines (due
to memory management requirements), you may not even be able to call
all the methods of the object (since they may pass the themselves as
parameters to other objects which invoke memory management
requirements). Only if you wrote your own entire hierarchies could
you use such a construction (or if you implemented full closures,
which is even more difficult in a C based language) . There's a whole
raft of semantics associated with Cocoa objects (above and beyond
anything that whatever version of the objective-c runtime may require).
If you can't use the object, have you actually created it?
As you can see, and the code clearly demonstrates, my original
assertion stands.
One could also manually construct a C++ vtable and set up all the
magic "behind the scenes" plumbing that a C++ object has, but that
doesn't mean that C++ object are ' synonymous for "Structs" ' either.
The point is that they are not synonymous for structs - if they were,
you could replace one with the other, and both Objective-C and C++
objects have additional semantic requirements.
As you can see, it's very clear where "isa" comes from. Subclassing
an object has the effect of "pasting" your ivar declarations at the
end of the class you're inheriting from, and forms the cause of
"fragile classes" since a struct effectively becomes pointer +
offset, and changing a struct requires recompiling code to update
those offsets.
Except, of course, for 64 bit Objective-C 2.0 which doesn't have these
problems (which makes the exercise of trying to allocate it on the
stack even more problematic).
So, no, there are no magic invisible members.
But there are semanticly required members that aren't in "plain"
structs.
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | flame : flame fractals & strange attractors : build,
mutate, evolve, animate
_______________________________________________
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