In response to Jens Alfke's suggestion of:
// MyObjCClass.h
#ifdef __cplusplus
class MyCppClass;
#else
typedef struct MyCppClass MyCppClass;
#endif
@interface MyObjCClass {
@private
MyCppClass *cppObject;
}
....
@end
On 28 May 2008, at 12:14 AM, Bill Bumgarner wrote:
On May 27, 2008, at 9:09 PM, Jens Alfke wrote:
On 27 May '08, at 8:59 PM, Bill Bumgarner wrote:
In this case, it will change the way that GC handles the pointer,
depending on how the class is compiled. GC is aware of the layout
of objects and will scan only the fields that are marked __strong
or are of an Objective-C object reference type.
But the pointer that's being lied about here is to a C++ object,
which the collector should be ignoring anyway, right?
Unless you were to compile the class such that the objective-c world
sees it as an Objective-C object pointer... Then it would be
scanned as if it were rooted in the GC world and, potentially, bad
things could happen.
Jens is probably wise by now, but I am still confused (I think I have
a block on the nuances of GC). In the sample code, cppObject is either
a pointer to a C++ object, or a pointer to an anonymous struct,
depending on whether the header is #included by an .mm or .m file.
Neither pointer seems to be to an Objective-C object. How then do your
strictures on crossing ObjC objects with struct pointers apply here?
I get the problem with disguising an ObjC pointer as a void* or
struct*. I hadn't thought of that, and am grateful to learn of it.
Related: Has alternative documentation emerged on GC, so I can get
over my block?
— F
_______________________________________________
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 [EMAIL PROTECTED]
