I had tried NSCollectorDisabled flag on NSAllocateCollectable but when
I do this I get cryptic errors from ibtool when compiling the main
project. The errors seem to be of the same nature I am seeing
elsewhere (things like unrecognized selector sent to instance -
[NSString count] unrecognized) where memory space is not encountering
what is expected. I am not sure what that means but am guessing that
some of the data in that struct that stores control state
(backgroundColor, etc) is experiencing problems with this change. I do
not know how to debug such a thing and it kind of seems like I am just
pushing the problem from one place to the next. That option just
doesn't seem to do what one would hope.
The private void ivar is another matter. I assume you are talking
about this macro:
// Macro for easily getting to the private data structure of an object.
#define myPrivateData ((SMPieChartPrivateData *)_SMPieChartView_Private)
Would the __strong version be coded as such?
#define myPrivateData ((SMPieChartPrivateData __strong
*)_SMPieChartView_Private)
I think I may have begun to descend the slippery slope. I have looked
at the struct and agree about objectifying it but it is so
foundational to the project I am afraid I will nearly be rewriting the
whole enchilada to do that. That is not in the cards as I probably
have a couple more stabs at this and then I will either decide to de-
GC my main project (at least I understand that code inside and out) or
just punt and hope to find a better chart package.
As an aside, I have seen previous discussion about getting access to
Apples own charting tools (Activity Monitor being an example), has
anybody had success in doing so?
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 gpar...@apple.com Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
