On Aug 11, 2005, at 3:41 AM, Nathaniel Gray wrote:
On Aug 10, 2005, at 6:56 PM, Sherm Pendley wrote:
I think those details are pretty well hidden by the marg_* macros
though. I've used method_getArgumentInfo() to get the offset of
the argument, and marg_setValue() to set it before calling
objc_msgSendv(). It worked fine with all sorts of types, including
floats and doubles.
Really? That's exactly what I'm doing. For a test case I wrote a
class OCOCTestCall with a class method
I would have sworn under oath that I did the same thing... but
looking at the old CamelBones code in CVS, I see that it uses
NSInvocation. I may have done some experiments with marg_* & friends,
but if so I didn't check the code in - which is actually a sign that
I never got it working properly. I haven't touched the older 0.2.x
tree in almost 18 months though. Sorry for the confusion. :-(
I did attempt to use marg_* & friends when switching to the 1.0.x
tree. The older version used simple message forwarding through a
proxy object. The current version registers Perl classes with the
runtime, so they're full peers that can participate in inheritance.
The objc_msgSend() (& _stret) functions are used for messages from
Perl to native code. I call them using ffcall. I *tried* to use
objc_msgSendv(), but got tripped up when I wanted to call super
methods from within Perl subclasses. As I said, there's no "v"
version of msgSendSuper().
Registered Perl methods all share the same IMP, which examines its
self and _cmd arguments to figure out what Perl method to call. It
then uses the registered method signature and standard varargs macros
to pull arguments off the C stack and build up Perl's calling stack.
Hmm. I looked at libffi but the release notes said it didn't
support vararg functions.
I'm using ffcall, actually. Same idea though.
Neither one *directly* supports varargs. You have to know at run-time
(or be able to figure out) the number of arguments you're passing to
the function, and their types. But, if you do know that, you can pass
them to a function that's been prototyped as accepting a variable
number of arguments.
I'll have to look again. Maybe I'll take a look at your code. :-)
Feel free - you might also want to have a look at the PyObjC and
RubyCocoa bridges.
Incidentally, I'm writing an Objective-C wrapper for OCaml, so your
code is more than a little bit relevant.
Cool - more options. Options are good. :-)
The problem I found was that there's no "v" (at least none that's
documented) equivalent to the objc_msgSendSuper() function. What I
settled on doing was using ffcall to call the "normal"
msgSendSuper functions, rather than the marg_* macros and the "v"
functions.
if you have a pointer to the object's Class can't you use the
super_class field to get access to superclass methods? Maybe I'm
missing something?
You *could* do that, climbing up the class definitions until you
found the IMP to call, then using ffcall/ffi to call it directly.
I chose not to, because it's basically redundant. The objc runtime
already has all the code to look up a method, starting at a
particular point in the inheritance tree, and I didn't feel like
reinventing that wheel. Apple's wheel is likely to be rounder than
mine would be too - it's very efficient, and caches the results from
frequently-called lookups.
What's more, doing so wouldn't really save me anything - once I found
the correct IMP, I'd *still* have to use ffcall/ffi to call it, with
more or less the same code I'm using to call objc_msgSendv().
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/objc-language/email@hidden
