Re: Garbage collected and non-garbage collected
Re: Garbage collected and non-garbage collected
- Subject: Re: Garbage collected and non-garbage collected
- From: Robert Mullen <email@hidden>
- Date: Thu, 12 Mar 2009 11:33:53 -0700
OK, I took a step back today and reconvened the knowledge you guys
have shared, reread the Hillegass chapter on GC (what a great book!!),
and reviewed the approaches I had taken. One thing that jumped out at
me was that I had not revisited the flags:
_SM2DGraphView_Private =
NSAllocateCollectable(sizeof(SM2DPrivateData), NSScannedOption|
NSCollectorDisabledOption);
with the __strong declaration on the private data object. If I use
both flags as shown above (which is what was originally suggested by
Greg Parker AND the __strong declaration on
#define myPrivateData ((SM2DPrivateData __strong *)
_SM2DGraphView_Private)
the framework compiles, my project compiles with it and miracle of
miracles it appears to run fully. Obviously I need to put this through
its paces but this is the only time I have had a successful run of
this inclusive project with GC on. Thanks to everybody who added a
little bit, each piece has helped me to understand the whole better
even if the project eventually fails.
Can anybody see obvious problems in what I did above?
TIA
On Mar 11, 2009, at 5:14 PM, Greg Parker wrote:
On Mar 11, 2009, at 4:31 PM, Robert Mullen wrote:
Approach 2 seems appealing but my initial go at it went less than
sterling. All access to the struct appears to be incorrect and
whereas most of the data contained before seemed to have integrity
now it almost immediately bombs with either EXC_BAD_ACCESS or it
gets an object other than what it was expecting. Which it gets is
pretty well random to my eyes making debugging a bit of an
adventure. What I did was to mark all the pointer types in the
struct with __strong so where it used to look like:
[...]
Good.
I then changed the calloc()s to use NSAllocateCollectable:
_SM2DGraphView_Private = calloc( 1, sizeof(SM2DPrivateData) );
becomes
_SM2DGraphView_Private =
NSAllocateCollectable(sizeof(SM2DPrivateData), NSScannedOption);
The collector treats this struct as a garbage-collected block, which
won't work unless you find all pointers to this struct and make the
same __strong / NSAllocateCollectable changes to them. If you add
NSCollectorDisabledOption, then this struct works more like ordinary
memory that you have to free() by hand.
In particular, the code I found on the Internet has
_SM2DGraphView_Private as a void* ivar. The collector does not look
for GC pointers inside void* ivars, so without
NSCollectorDisabledOption it'll throw the object away. Either add
NSCollectorDisabledOption() and free() the struct later; or make
_SM2DGraphView_Private a `__strong void *` and don't free it; or
make SM2DPrivateData a real Objective-C class and
_SM2DGraphView_Private an `SM2DPrivateData *`.
(Should this be _SM2DGraphView_Private = (SM2DPrivateData
*)NSAllocateCollectable(sizeof(SM2DPrivateData), NSScannedOption);
instead?)
Doesn't matter for GC purposes.
and assignment to the struct members is done like this:
myPrivateData->borderColor = [ [ NSColor blackColor ] retain ];
Do I need to remove the copy and retain semantics from each of
these as well? I was under the impression that the GC would just
ignore these since it was using its own cleaning mechanism and that
they could be left as is.
You're correct. -retain is ignored when GC is on. (CFRetain is not
ignored. If there are any CFRetain or CFRelease calls in the code,
or any CFCreate or CFCopy calls, then you may need more work to make
retain counts balance. CFRetain and -retain are not toll-free under
GC.)
I am not sure where to go from here. I beat my head against it a
fair bit today and am learning more about GC and non-GC code but am
struggling to get over the hump. I am going to crack open the
Hillegass book again tomorrow and reread the GC chapter in hope
that a light bulb will go off. From what I read today though I
would have thought the above would have worked.
Interfacing GC code with ordinary C code is hard. There are lots of
holes to fall into, and it's hard to tell where they are until you
crash.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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