Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful

FROM : glenn andreas
DATE : Thu Feb 07 04:01:45 2008

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);
> }
> [<email_removed>] /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
> [<email_removed>] /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_removed>
  <http://www.gandreas.com/> wicked fun!
quadrium | flame : flame fractals & strange attractors : build, 
mutate, evolve, animate