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 <supp...@turtlesoft.com> 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 (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/zav%40mac.com
> 
> This email sent to z...@mac.com
_______________________________________________

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

Reply via email to