Re: C++ pointer to Cocoa object
Re: C++ pointer to Cocoa object
- Subject: Re: C++ pointer to Cocoa object
- From: Alex Zavatone <email@hidden>
- Date: Fri, 07 Sep 2018 18:46:36 -0500
I ran into this while writing wrappers for pjsip in C++ to Obj-C and vice versa.
The only conclusion that I came to was to store what the valid pointer value
was after it was created. The failure cases could be an undefined or out of
range pointer but they proved not easily able to test for. All I could
reliably test for was a known good pointer value, so that’s what I did.
What I did was assume that if a wrapping Obj-C class which allocated the C++
object was valid, that the C++ object was valid and then store the pointer
values. If at any time the pointers changed I could not assume that they were
pointing to a valid location, so recreate the C++ object again and store the
new pointers. It worked.
IIRC, I think I also passed in a weak reference to the Obj-C class so that the
C++ functions could access the container. Passing data back and forth by
casting was a little tricky. I can look at what we did to work with this this
when I get back home
I’m sure it’s not best, but it never crashed for us. I would love to hear more
of a real solution if anyone has one.
Hope this helps.
Alex
Sent from my iPhone
> On Sep 7, 2018, at 12:46 PM, Casey McDermott <email@hidden> 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?
>
> Thanks,
>
> Casey McDermott
> TurtleSoft.com
> _______________________________________________
>
> 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
_______________________________________________
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