On 8 Sep 2018, at 15:32, Casey McDermott wrote:
>
>>> If you are using ARC and want to get a strong
> reference on the object, you have to use __bridge_retained
>
> That is handy to know! I see there is also __bridge_transfer to go the other
> way.
IMO the Core Foundation wrappers CFBridgingR
>> If you are using ARC and want to get a strong
reference on the object, you have to use __bridge_retained
That is handy to know! I see there is also __bridge_transfer to go the other
way.
In this case we put the Cocoa controls into a NSView, which releases them.
The NSView deletes our LView,
> Le 7 sept. 2018 à 19:46, Casey McDermott a écrit :
>
> 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
>> NSAtom is a red herring
Quite possible.
Usually we create the C++ object, which constructs a linker in the next line or
two.
Then that creates the Cocoa object in the next line or two and hooks them up.
They all stick around until all are deleted. Not much chance for object
lifetime prob
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. A
> On Sep 7, 2018, at 3:48 PM, Jens Alfke wrote:
>
>> On Sep 7, 2018, at 10:46 AM, Casey McDermott wrote:
>>
>> Problem is, with ARC turned on, the pointer is never nil, so it crashes.
>> The void pointer somehow becomes an NSAtom instead of 0.
>
> Something wrote to that pointer, then. If y
> On Sep 7, 2018, at 10:46 AM, Casey McDermott wrote:
>
> Problem is, with ARC turned on, the pointer is never nil, so it crashes.
> The void pointer somehow becomes an NSAtom instead of 0.
Something wrote to that pointer, then. If you initialize it to nullptr, it will
stay that way. NSAtom
Usually the way you get an NSAtom is because you’re reading garbage–either
somebody scribbled over your pointer or it was garbage to begin with. Does
mCocoaPopupPtr ever get set to nil? Does it have a consistent value? What
happens if you run with the Address Sanitizer enabled, or with NSZombieE
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 ca
You might also find WWDC 2018, Session 409, informative.
--
Gary L. Wade
http://www.garywade.com/
> On Sep 7, 2018, at 1:44 PM, Allan Odgaard wrote:
>
>> On 7 Sep 2018, at 19:46, Casey McDermott wrote:
>>
>> Problem is, with ARC turned on, the pointer is never nil, so it crashes.
>> The void po
On 7 Sep 2018, at 19:46, Casey McDermott wrote:
Problem is, with ARC turned on, the pointer is never nil, so it
crashes.
The void pointer somehow becomes an NSAtom instead of 0.
Nil is nil, I think your issue is rather that you do not properly retain
the pointer before storing it as void*.
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
12 matches
Mail list logo
