• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: calling method via IMP that returns non id type - compiler warning
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: "b.bum" <email@hidden>
  • Date: Sun, 15 Feb 2004 18:29:26 -0800

On Feb 15, 2004, at 4:25 PM, Ben Dougall wrote:
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.
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.

Though it is tempting to go with what appears to work, not understanding why it does or does not work is a bad idea -- as it is, it is working merely by coincidence. If you break that coincidence, you are in for some long hours of not very fun debugging. I would highly recommend understanding the C language thoroughly before trying to do things like this -- it'll save you quite a bit of frustration at some point. (I speak from some rather painfully gained experience -- I took the "oh, look, it just works... yay... i have no idea why, but i don't care.... oh, crap, 20 hours of debugging in GDB only to figure out that it was just a coincidence..." approach to understanding C pointers).

Looking at the docs (searched google for "IMP instanceMethodForSelector declaration"):

http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ ObjC_classic/Classes/NSObject.html

And it would appear that you likely need a declaration like:

MyType *(*theMethodIMP)(id, SEL, unsigned);

Note the extra *. Isn't C fun?

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).

....

- 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.

This is an extremely uncommon pattern to use. The overhead of a method invocation is trivial in comparison to drawing, event handling, I/O or any of a number of other random things that may happen in your app.

Unless you have some kind of a tight loop or have instrumented your code and determined that the normal usage pattern really is a performance bottleneck [extremely unlikely], doing this kind of optimization this early in the development cycle will cause more problems than it solves. It makes it very difficult to refactor the code or generalize the classes into reusable APIs.

In doing performance optimization on various random ObjC apps over the years, I have yet to run across a situation where direct IMP access has yielded a useful performance boost outside of the tightest of loops. Most benefit has come from avoiding the execution of code through the use of aggressive caching, lazy evaluation, optimized drawing, and/or communications protocol optimization. All of these are much easier to do-- both instrument and to refactor the actual code-- if there hasn't been misdirected optimizations that move the code away from being a pure OO model.

b.bum
_______________________________________________
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.

  • Follow-Ups:
    • Re: calling method via IMP that returns non id type - compiler warning
      • From: Ben Dougall <email@hidden>
    • Re: calling method via IMP that returns non id type - compiler warning
      • From: "Louis C. Sacha" <email@hidden>
References: 
 >Re: calling method via IMP that returns non id type - compiler warning (From: Ben Dougall <email@hidden>)

  • Prev by Date: loading a data source having missing columns
  • Next by Date: Re: ABPerson is a Person or a Company
  • Previous by thread: Re: calling method via IMP that returns non id type - compiler warning
  • Next by thread: Re: calling method via IMP that returns non id type - compiler warning
  • Index(es):
    • Date
    • Thread