Re: [cffi-devel] calls with variable number of arguments which are determined at run-time
Lars Rune Nøstdal larsnostdal@gmail.com writes:
Anyone have some suggestions as to how I can call foreign-functions with variable number (the count, types and values determined at run-time!) of arguments?
I've nagged the CLL'ers about this and Pillsy came up with a hack that works:
I was wondering if there where better ways to do this?
Hi Lars,
Off the top of my head, I think any reasonable approach is going to need to involve calling the compiler. Only the compiler knows how to actually build the stack frames and such for the call. For example, there are arcane rules on some architectures about whether floating point values are passed on the stack or in registers depending on the number of arguments and their positions.
One possibility for making it a little less gruesome performance-wise is to build a cache of precompiled functions for a set of function types. For each distinct set of argument types you can COMPILE a lambda that builds the appropriate FOREIGN-FUNCALL, and store it in an EQUAL hashtable with the list of arguments (:INT :FLOAT).
What's the use case for this? Surely not sprintf; there's about a million better ways to format text without resorting to such things... ;-)
Down with varargs!
James
James Bielman <jamesjb <at> gmail.com> writes:
What's the use case for this?
Short answer: `g_object_new'.
I'm trying to (re)write some simple GTK+ bindings which are going to focus more on generating bindings via GObject's reflection/introspection-features than going through the "parse C headers"-path.
Down with varargs!
Yeah, same with C-macros.
Thanks for the tip. The caching-idea might work. I'd only need to cache for properties that are flagged `G_PARAM_CONSTRUCT_ONLY'.
If I'm not able to figure something out there I'll have to dive into `g_object_newv' which seem(ed) way more complicated that `g_object_new'. :)
On Fri, Feb 09, 2007 at 10:14:38AM +0000, Lars Rune Nøstdal wrote:
James Bielman <jamesjb <at> gmail.com> writes:
What's the use case for this?
Short answer: `g_object_new'.
how many possible ways of using g_object_new do you have ? if not too many perhaps you could so somethig like this:
(defsyscall ("fcntl" %fcntl-without-arg) :int :noexport (fd :int) (cmd :int))
(defsyscall ("fcntl" %fcntl-with-int-arg) :int :noexport (fd :int) (cmd :int) (arg :int))
(defsyscall ("fcntl" %fcntl-with-pointer-arg) :int :noexport (fd :int) (cmd :int) (arg :pointer))
(define-entry-point fcntl (fd cmd &optional (arg nil argp)) (cond ((not argp) (%fcntl-without-arg fd cmd)) ((integerp arg) (%fcntl-with-int-arg fd cmd arg)) ((pointerp arg) (%fcntl-with-pointer-arg fd cmd arg)) (t (error "Wrong argument to fcntl: ~S" arg))))
(defsyscall is a wrapper around foreign-funcall and define-entry-point does only a defun+export)
On Fri, 2007-02-09 at 10:14 +0000, Lars Rune Nøstdal wrote:
James Bielman <jamesjb <at> gmail.com> writes:
What's the use case for this?
Short answer: `g_object_new'.
I'm no GTK expert, but looking at the documentation it looks like there's a `g_object_newv' that takes an array of value objects instead of using varargs. I did see some scary looking macros there too, so maybe that's just as hard.
One of these days I'm going to write a article/blog entry about how to write C libraries that aren't completely hostile to people using other languages. As if anyone would care...
Sigh!
James
-
James Bielman -
James Bielman -
Lars Rune Nøstdal -
Stelian Ionescu