Re: calling method via IMP that returns non id type - compiler warning
Re: calling method via IMP that returns non id type - compiler warning
- Subject: Re: calling method via IMP that returns non id type - compiler warning
- From: Ben Dougall <email@hidden>
- Date: Mon, 16 Feb 2004 00:25:54 +0000
On Sunday, February 15, 2004, at 06:59 pm, b.bum wrote:
On Feb 15, 2004, at 8:59 AM, Ben Dougall wrote:
i've used an IMP to call a method, and that method returns a
typedeffed type that isn't an object pointer -- not an id type that
is. it all works fine apart from it gives a warning. if i cast the
returned value from the IMP call the warning goes away -- but is that
the way to fix that?
Most likely, you haven't declared the type of theMethodIMP
appropriately. It shouldn't just be IMP, but needs to be specific to
the signature of the method you are invoking.
yes that's what i'm doing. in the .h:
extern IMP theMethodIMP;
and in the .m:
IMP theMethodIMP = nil;
then the set up of the IMP is:
SEL sel = @selector(theMethod:);
theMethodIMP = [object methodForSelector:sel];
I.e. something like.....
MyType (*theMethodIMP)(id, SEL, unsigned);
i tried amongst other things this in the .h:
extern MyType (*theMethodIMP)(id, SEL, unsigned);
and in the .m:
MyType *theMethodIMP = nil;
or
MyType (*theMethodIMP)(id, SEL, unsigned) = nil;
:/ i don't know.
can't get it to work. i'll just cast the return of the call via IMP --
seems to work fine.
theMethodIMP = ... instanceMethodForSelector: ...
result = theMethodIMP(self, @selector(theMethod:), value)
(all typed in email -- you'll have to figure out the exact syntax for
the decl if that isn't right).
BUT two issues:
- you really should pass the SEL of the method in the IMP call. If
you don't, _cmd will be undefined within the body of the method.
While that may not cause a problem now, it will if you ever happen to
use a macro that uses it (NSASSERT()) or someone overrides and
provides an implementation that relies upon a defined _cmd.
ok, will do.
- why are you doing this in the first place? Is there some reason
not to use NSInvocation or just invoke the method as you normally
would? Generally, calling the IMP directly is a performance
optimization only used in extreme cases. Have you identified a
performance hit that warrants such a solution? (You might have -- I
don't know -- but I do know that just about every time this has ever
come up on the list(s), it has been a case of "premature
optimization").
no i haven't identified a performance problem because the app doesn't
exist yet really. the reason i'm doing it is because this is a fixed
method of a singleton that i know will be called many times throughout
the code -- i don't want or need any dynamic/flexible behaviour for
this particular method so because i can access it via an IMP i might
aswell.
thanks, ben.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.