On 9/7/18 10:46 AM, Casey McDermott wrote:
We need to link some of our C++ classes to a matching Cocoa class.
It's easy for Cocoa to reference C++ objects. Going the other way is harder.
We have been using a linker class that has a void pointer to the Obj-C object
in the C++ header. We then cast it to a Cocoa object in the Obj-C++ source.
For example, in the C++ header we have:
void *mCocoaPopupPtr = nil;
Then in the source:
void GSCocoaPopupLinker::setCocoaFieldVisible(const BOOL inValue)
{
if (mCocoaPopupPtr != nil)
{
GSPopupButton *cocoaPopup = (__bridge GSPopupButton
*)mCocoaPopupPtr;
[cocoaPopup setHidden : !inValue];
}
}
Problem is, with ARC turned on, the pointer is never nil, so it crashes.
The void pointer somehow becomes an NSAtom instead of 0.
There's very little documentation on NSAtom, but it appears to be Apple's way to
use the excess bits in a 64-bit address to store class info.
Is there some other way to test for an invalid void pointer?
I don't use ARC, so I'm just speculating here, but maybe a solution
would be to use the private implementation pattern. That is, in your
public C++ header, the only member would look like
std::unique_ptr< MyClassImp > _imp;
MyClassImp would be declared and defined only in the Objective-C++
source file (except for a forward declaration in the C++ header), so it
could use proper Objective-C types as members.
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
