Yeah yeah... I'm running a little behind. Nothing unusual there. ;)
On Mon 09/18, Tor Lillqvist < [EMAIL PROTECTED] > wrote: > Felix Kater writes: > > g_module_* is a great thing -- I just wonder if there is a way > > to not create function pointers for each single function I need > > but just import all of them at once? > Define a "suite" struct containing all the function pointers for > your module, and then export just one function that returns a > pointer to such a struct? Please have in the struct as its first > member an int with the size of the struct, for the version of the > module in question. When adding function pointers to your struct, > add them to the end, keeping the previous fields intact. You *will* > be glad later when you have different versions of your module and > different versions of client apps deployed in the wild that you did > that ;) Iterating the library for symbols would be nice, though I'm assuming it comes with complications since it's not often done. eg. You still need to specify the location into which to store those symbol locations. I've seen the exported struct of functions done quite effectively, but altering the set of functions in the API at a latter date becomes a problem. You end up with gaps in the list, and it gets annoying calling functions via the struct so you end up with a matching bunch of #define's or even wrapper functions. Although, I suppose it does mean that you don't actually need to export any symbols, except the initialiser function. Which might actually have its own benefits. On the other hand, if the API is prone to evolution, such as in the early stages, the practice of grabbing a symbol at a time could be beneficial, so long as you're only adding and removing functions. To make life a little easier, you could well have a struct describing the name of the function you want, and where to shove its function pointer. You can then run an array of such structs with a small function, filling in the function pointers as it goes along (and maybe target any it can't find at a "symbol not found" abort function). Finally, even if you can't get the linker to do the work for you, you could probably get the compiler or some other tool to export a list of symbols, and build a header with the array of symbols and pointer storage variables for you. I've used such techniques to build source file version number dump includes for debugging use. Fredderic _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
