I have a function that looks like this:
void myMethodImpl(id self, SEL _cmd, ...)
I use this as a implementation for a method on a class
class_addMethod(aClass, aSelector, (IMP)myMethodImpl, types);
so myMethodImpl get's called when a message is sent to aClass with selector aSelector. Now there I'd like to create an NSInvocation with all parameters from myMethodImpl.
Is there an easy way to create a NSInvocation from the parameter list or do I have to check every element for it's type and add it accordingly?
Since you're adding a method to the class, why not add/swizzle forwardInvocation: instead? At that point the runtime will have nicely built an invocation for you.
This is not possible. A simple google search shows this article:
http://www.wincent.com/a/about/wincent/weblog/archives/2006/03/nsinvocation_an.php
Which clearly explains how va_args don't properly work with NSInvocation.
It is possible, indeed. Have a look to the actionSelectorImplementation function in https://github.com/rlopezdiez/TMInstanceMethodSwizzler/blob/master/Classes/TMInstanceMethodSwizzler.m
Related
I have a C struct that contains a function pointer. Now, I have used this setup within C with no problems, but now I'm using this C struct in Objective-C and I need to pass a function (or selector) pointer that is defined in the Objective-C class.
1. Here is what I have for the Objective-C selector that needs to be passed as a pointer to the C function:
- (void)myObjCSelector:(int*)myIntArray
{
// Do whatever I need with myIntArray
}
2. And here is where I run into a wall, Within Objective-C I'm trying to pass the selector as a pointer to the C function call: In place of "myObjCSelectorPointer" I need the proper syntax to pass the selector as a function pointer in this C function call:
passObjCSelectorPointerToCContext(cContextReference, myObjCSelectorPointer);
I did investigate this issue, but could mainly find several different ways of doing similar things, but I couldn't find anything specific for calling C functions and passing an Objective-C selector pointer.
In objc a selector is not a function pointer. A selector is a unique integer that is mapped to a string in a method lookup table stored by the objc runtime. In the above case your method name would be myObjCSelector: and to get the unique selector for it you would type #selector(myObjCSelector:). However this would be of no use to you because it doesnt represent a particular implementation of a function.
What youre looking for is IMP. Refer to this SO question.
EDIT 2:
IMP myObjCSelectorPointer = (void (*)(id,SEL,int*))[self methodForSelector:#selector(myObjCSelector:)];
Then you can call the method using
myObjCSelectorPointer(self,#selector(myObjCSelector:),myIntArray);
However, what this means you will need to make sure that you add the pointer to self in the c function call passObjCSelectorPointerToCContext.
So it should look like this
passObjCSelectorPointerToCContext(cContextReference, self, myObjCSelectorPointer);
when called from within the object that contains the method.
It is important to note though that using IMP is almost never the right technique. You should try to stick with pure Obj-C. Obj-C is quite efficient after the first call to a message because it uses temporal caching.
EDIT 1:
It's useful to understand why objc works in this way. The Apple documents explain it in depth. However a short explanation is as follows:
When you send a message to an object such as [myobject somemethod] the compiler won't immediately know which particular implementation of somemethod to call because there might be multiple classes with multiple overriden versions of somemethod. All of those methods have the same selector, irrespective of its arguments and return values and hence the decision about which implementation of somemethod is deffered to when the program is running. [myobject somemethod] gets converted by the compiler into a C function call:
objc_msgSend(myobject, #selector(somemethod))
This is a special function that searches each myobject class layout to see whether that class knows how to respond to a somemethod message. If not it then searches that class's parent and so on until the root. If none of the classes can respond to somemethod then NSObject defines a private method called forward where all unknown messages are sent.
Assuming that a class can respond to the somemethod message then it will also have a particular pointer of type IMP that points to the actual implementation of the method. At that point the method will be called.
There is considerably more to this procedure than I have described but the outline should be enough to help you understand what the goal of a selector is.
One final point is that the reason method names are mapped to unique integers via the #selector directive is so that the runtime doesn't have to waste time doing string comparisons.
Basically, the answer is: Objective-C selectors are different from function pointers. You need two pieces of data to perform a selector. That is an object and the selector itself. You will need some glue to accomplish your task.
Check this question.
Do you have to use a function pointer? In Objective-C, you can get the function pointer to an arbitrary method implementation (known as an IMP), but this is extremely uncommon, and usually not a good idea. Calling objc_msgSend() directly is also not the greatest idea, because there are several different variants of objc_msgSend(), and the compiler automatically chooses different ones to use based on the return type of the method. Methods that return an object go through objc_msgSend(), but objects that return structs might go through objc_msgSend() or they might go through objc_msgSend_stret(). And if the method returns a double, then it goes through objc_msgSend_fpret()...
Documentation: Objective-C Runtime Reference: Sending Messages
Instead, I might recommend using a target-action pair, or using a block. Then you might do something like:
myContextRef->target = anObjcObject;
myContextRef->action = #selector(invokeMe:);
And when you're done, do:
[myContextRef->target performSelector:myContextRef->action withObject:someReturnInformation];
Or maybe use a block:
myContextRef->completionHandler = [^(id returnInformation) {
[anObjcObject invokeMe:returnInformation];
} copy];
And then when you're done, do:
myContextRef->completionHandler(someReturnInformation);
(and don't forget to -release the block when you free the context)
How do I formulate
[NSClassFromString(classname) myMethod:param1 more:param2];
such that the compiler does not give a warning saying that +myMethod may not be implemented ?
[NSClassFromString(classname) performSelector: #selector(myMethod:more:) withObject:param1 withObject:param2];
Quick & dirty: cast the return of NSClassFromString to id, if myMethod:more: is unique. The method binding doesn't happen until runtime, so the correct impl will be called.
Slightly cleaner: use NSObject's -(id)performSelector:(SEL)aSelector withObject:(id)anObject withObject:(id)anotherObject, if param1 and param2 are ids. It works for class methods too when called on a class object.
Well, since you have multiple arguments, you can’t use -performSelector:withObject:. You’ll have to use what Objective-C uses under the hood, objc_msgSend(). But first you’ll have to cast it. Here’s how:
In your implementation file (.m), add the line #import <objc/message.h> to the top. Then, you need to cast objc_msgSend() appropriately. In this example, we’ll assume that param1 and param2 are Objective-C objects and that -myMethod:more: returns void.
void (*myMsgSend)(id self, SEL _cmd, id param1, id param2);
myMsgSend = (void(*)(id, SEL, id, id))objc_msgSend;
Once you’ve cast it appropriately, call your new function:
myMsgSend(obj, #selector(myMethod:more:), param1, param2);
Try typecasting the value returned by NSClassFromString() to id first.
Is it possible to use #selector and performSelector: (or similar) with methods using variable arguments list?
I'm writing a class that can be assigned a delegate to override the default behavior. In the presence of a delegate select method calls made on an instance of that class will be forward to the same corresponding delegate method, some which use variable argument lists.
So, for instance, I need to be able to create retrieve SEL reference and message the delegate object with a method such as this:
- (void)logEventWithFormat:(NSString *)format, ... {
va_list argList;
id del = self.delegate;
if (del != nil &&
[del conformsToProtocol:#protocol(AProtocolWithOptionalMethods)] &&
[del respondsToSelector:#selector(logEventWithFormat:)])
{
// Perform selector on object 'del' with 'argList'
}
}
I am assuming this is not possible, hence the similar method declaration in the Foundation framework - in NSString:
- (id)initWithFormat:(NSString*)format, ...;
and
- (id)initWithFormat:(NSString *)format arguments:(va_list)argList;
I assume that the protocol I wish to delegate to should suggest the implementation of:
- (void)logEventWithFormat:(NSString *)format arguments:(va_list)argList;
so I the selector #selector(logEventWithFormat:arguments:) can be used an called with:
[del performSelector:#selector(logEventWithFormat:arguments:)
withObject:format
withObject:argList];
I just wondered if I was missing something or going the long way around to achieve what I'm trying to?
You can pass anything you want into the runtime function objc_msgSend.
objc_msgSend(del, #selector(logEventWithFormat:arguments:), format, argList);
It's the most powerful way of sending a manually constructed message.
However, it's not clear that you need to perform the invocation this way. As KennyTM pointed out, in the code you have, you could invoke the method directly.
You can't use -performSelector:withObject:withObject: because va_list simply isn't an "object". You need to use NSInvocation.
Or simply call
[del logEventWithFormat:format arguments:argList];
As far as I know, it can't be done. You can't use -performSelector:withObject:withObject: because as #KennyTM points out, a va_list isn't an object.
However, you also cannot use NSInvocation. The documentation straight up says so:
NSInvocation does not support
invocations of methods with either
variable numbers of arguments or union
arguments.
Since these are the two ways of invoking a method by selector, and neither seems to work, I'm going to go with the "can't be done" answer, unless you invoke the method directly and pass the va_list as an argument.
Perhaps #bbum will show up and enlighten us further. =)
I haven't done it that way before, but the simple solution I've often used is to box/unbox either an NSMutableArray or an NSMutableDictionary for the withObject parameter.
I have two methods with same name but different parameters say:
-(void)methodA:(NSString*)string
-(void)methodA:(NSNotification*)notification
Now i need to call those methods using #selector with the parameters. How to do it ?
SEL aSel = #selector(methodA:);
[objectTakesString performSelector:aSel withObject:#"A string!"];
[objectTakesNtfctn performSelector:aSel withObject:[NSNotification notificationWith...]];
-[NSObject performSelector:withObject:] takes both the selector to be invoked, and a pointer to the parameter to pass it.
In my opinion, both the preceding answers are wrong. If you use
-[NSObject performSelector:withObject:];
as Sixten Otto suggests, you would have to place this at the beginning of your method:
-(void)methodA:(id)stringOrNotification
{
if ([stringOrNotification isKindOfClass:[NSString class])
{
..do something..
}
if ([stringOrNotification isKindOfClass:[NSNotification class])
{
..do something else..
}
. . .
}
Apart from this (bad) approach, what you're asking for can't in fact (easily) be done in Objective-C, because the language doesn't support parametric polymorphism. In other words, the type information is not used in the message dispatch. Yet another way to say this is that there can't be "two methods with same name but different parameters" in the same class. In fact, I'm surprised that you haven't yet seen a compiler error if you tried to declare this.
(If you've got the two methods defined on different classes, as dreamlax seems to assume, the message invocation will work trivially, even if you don't use performSelector:. Like so:
id eitherStringOrNotification;
[objectOfUncertainClass methodA:eitherStringOrNotification];
If that's what you're asking for, you don't have a problem.
)
Note that the NSMethodSignature object does contain information about the parameter types, but it's generated by the receiving object, so you can't really use it to distinguish between messages based on what parameter types are handed in (since that information is not available when the method signature is instantiated).
I know how to create a SEL at compile time using #selector(MyMethodName:) but what I want to do is create a selector dynamically from an NSString. Is this even possible?
What I can do:
SEL selector = #selector(doWork:);
[myobj respondsToSelector:selector];
What I want to do: (pseudo code, this obviously doesn't work)
SEL selector = selectorFromString(#"doWork");
[myobj respondsToSelector:selector];
I've been searching the Apple API docs, but haven't found a way that doesn't rely on the compile-time #selector(myTarget:) syntax.
I'm not an Objective-C programmer, merely a sympathizer, but maybe NSSelectorFromString is what you need. It's mentioned explicity in the Runtime Reference that you can use it to convert a string to a selector.
According to the XCode documentation, your psuedocode basically gets it right.
It’s most efficient to assign values to SEL variables at compile time with the #selector() directive. However, in some cases, a program may need to convert a character string to a selector at runtime. This can be done with the NSSelectorFromString function:
setWidthHeight = NSSelectorFromString(aBuffer);
Edit: Bummer, too slow. :P
I'd have to say that it's a little more complicated than the previous respondents' answers might suggest... if you indeed really want to create a selector... not just "call one" that you "have laying around"...
You need to create a function pointer that will be called by your "new" method.. so for a method like [self theMethod:(id)methodArg];, you'd write...
void (^impBlock)(id,id) = ^(id _self, id methodArg) {
[_self doSomethingWith:methodArg];
};
and then you need to generate the IMP block dynamically, this time, passing, "self", the SEL, and any arguments...
void(*impFunct)(id, SEL, id) = (void*) imp_implementationWithBlock(impBlock);
and add it to your class, along with an accurate method signature for the whole sucker (in this case "v#:#", void return, object caller, object argument)
class_addMethod(self.class, #selector(theMethod:), (IMP)impFunct, "v#:#");
You can see some good examples of this kind of runtime shenanigans, in one of my repos, here.
I know this has been answered for long ago, but still I wanna share. This can be done using sel_registerName too.
The example code in the question can be rewritten like this:
SEL selector = sel_registerName("doWork:");
[myobj respondsToSelector:selector];