Le 7 août 2013 à 17:32, Andy Lee <ag...@mac.com> a écrit :
> On Aug 7, 2013, at 3:47 AM, Jean-Daniel Dupas <devli...@shadowlab.org> wrote:
>> Instead of trying to use complex approach to hide the fact you need a
>> global, just use one, and don't try to reuse the existing one for things
>> there are not designed to do.
>>
>>
>> static id myCallbackHandler;
>>
>> void someCallBack() {
>> [myCallbackHandler handleCallBack];
>> }
>>
>> - (void)foo {
>> myCallbackHandler = self;
>> callCFunctionWithCallBack(someCallBack);
>> myCallbackHandler = nil;
>> }
>
> What if instance x does [x foo], and before someCallBack() gets called, some
> other instance y does [y foo]? There will be two future calls to
> someCallBack(), and [y handleCallBack] will be called both times, which is
> not the desired outcome. This is a problem with any approach where the
> callback looks in some global place, whether it's a static variable, a key
> path from the app delegate, or whatever.
> Even if you are sure you won't run into the problem of the global variable
> being overwritten, I think routing self through a global like
> myCallbackHandler is more complex than:
If you intend to use it from multiple threads, so use a tls.
__thread id myCallbackHandler;
I was talking about the case where you have to deal with a poorly design API
with no context pointer argument.
The case with a context argument should off course be handle the way you
describe.
> void someCallBack(void *contextPtr) {
> [[(MyClass *)contextPtr autorelease] handleCallBack];
> }
>
> - (void)foo {
> callCFunctionWithCallBack(someCallBack, (void *)[self retain]);
> }
>
> or with ARC:
>
> void someCallBack(void *contextPtr) {
> [(__bridge_retained MyClass *)contextPtr handleCallBack];
> }
>
> - (void)foo {
> callCFunctionWithCallBack(someCallBack, (__bridge_transfer void *)self);
> }
>
> This assumes that the API includes a context pointer, but realistically, how
> often won't that be the case? (I don't actually know.)
> --Andy
>
>>
>>
>> Le 30 juil. 2013 à 15:44, Maxthon Chan <xcvi...@me.com> a écrit :
>>
>>> My common way of handling this would be NSNotificationCenter. It is a
>>> singleton so I am always sure that it is there, and I can wrap all
>>> parameters into the userInfo dictionary.
>>>
>>> Sent from my iPhone
>>>
>>>> On 2013年7月30日, at 21:19, KappA <rejek...@gmail.com> wrote:
>>>>
>>>> I sometimes just access my objc-objects from a C thread-proc via the
>>>> AppDelegate (providing there's a trail to the object I need, which there
>>>> usually is)... If the callback void pointer parameter isn't being used for
>>>> something else, you can simply cast the object in there... or if you need
>>>> multiple parameters you can create a struct that stores what you need and
>>>> pass that. Not sure if this helps but figured I'd mention it.
>>>>
>>>> AppDelegate *d = [[UIApplication sharedApplication] delegate];
>>>>
>>>>
>>>>
>>>>> On Tue, Jul 30, 2013 at 8:53 AM, lowell <lowe...@me.com> wrote:
>>>>>
>>>>> The first two parameters to the function have to be an id and a SEL ...
>>>>>
>>>>> typedef id (*IMP)(id, SEL, ...);
>>>>>
>>>>> ... (this is where we get self and _cmd, by the way) followed by the rest
>>>>> of the method params, if any.
>>>>>
>>>>>
>>>>> lowell
>>>>>
>>>>>
>>>>>> On Jul 30, 2013, at 12:59 AM, Vincent Habchi <vi...@macports.org> wrote:
>>>>>>
>>>>>> Hi everybody,
>>>>>>
>>>>>> I have a very simple question: if I embed a C-function (more precisely,
>>>>> a callback from an external C-library) in an Obj-C object, can I expect
>>>>> this function to behave like a regular method? I.e. can it freely access
>>>>> ‘self’ and other attributes?
>>>>>>
>>>>>> Thanks a lot!
>>>>>> Vincent
>>>>>>
>
-- Jean-Daniel
_______________________________________________
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
