diff options
author | Søren Sandmann Pedersen <sandmann@daimi.au.dk> | 2009-04-13 21:46:30 -0400 |
---|---|---|
committer | Søren Sandmann Pedersen <sandmann@daimi.au.dk> | 2009-04-13 21:46:30 -0400 |
commit | 9726da802284076a486e23a5d09b7920f1260b8f (patch) | |
tree | 81cba722770b7310c243c45030e4ed4312437f00 | |
parent | e4e64159fe074ab44a048ca48f9e243bf71c6488 (diff) |
TODO
-rw-r--r-- | TODO | 27 |
1 files changed, 25 insertions, 2 deletions
@@ -61,11 +61,34 @@ passed to the function would go. Maybe that would just always go first. Ie., void on_clicked (void) { - printf ("clicked\n"); + printf ("clicked\n"); } Would require a dependency on macro varargs and on libffi closures. +libffi closures are not a problem. They are supported for all +relevant, and several irrelevant, architectures. Macro varargs - the +main issue might be msvc. Actually, it doesn't have to be a macro, it +could be a vararg function. It would require some way to specify the +end of the argument list though. Or just give the number of arguments: + + NUL_CALLBACK (function, 2, NUL_INT (x), NUL_INT (y)); + +If the NUL_INT constructors return a pointer, it would be easy to +check at runtime that the number of args is not an insanely big number +(say > 100 or < 0). + +If all callbacks are defined as trampolines, then it is possible to +have them be a struct with an optional destroy notifier embedded in +it. Ie., the NUL_CALLBACK would do something like this: + + nul_callback_info_t *info = malloc (sizeof (...)); + info->f = make_closure (f, ...); + info->destroy = free_callback_info + +where free_callback_info would free the closure and the callback info +plus any other house keeping. + Dbus: @@ -356,7 +379,7 @@ Highlevel design for a web server: nul_object_block (object, "birnan"); nul_object_unblock (object, "birnan"); - nul_object_connect (object, "birnan", on_birnan, DATA); +/ nul_object_connect (object, "birnan", on_birnan, DATA); */ |