|
From: Stephen S. <rad...@gm...> - 2013-04-12 12:13:57
|
Hi, I would like some feedback on this idea, pushed as a branch called 'options' Currently we now have a 'flags' API for lo_address and lo_server. Since this seems a bit inflexible as a general "options" mechanism, for future-proofing this design decision, I propose being able to at least provide an argument for each option, rather than only being able to specify boolean bitflags. https://github.com/radarsat1/liblo/commit/06e65feb559fe729fba077a5eb998d84d20c33cd In the proposal, each option is set individually with an argument, eg, lo_address_set_option(a, LO_ADDRESS_SLIP, (void *)1); As you can see, a downside of reserving the argument as a void* pointer is that it requires an ugly cast for integer/boolean arguments. I haven't figured out a better way to do this. The only other suggestion I had was to use a union called lo_option, allowing, typedef union { char *s; void *p; int i; } lo_option; lo_address_set_option(a, LO_ADDRESS_SLIP, (lo_option)1); But this still requires an explicit cast and depends on a GNU C extension. Although, I believe the following is valid C99: lo_address_set_option(a, LO_ADDRESS_SLIP, (lo_option){1}); Either way it's a bit uglier than I was hoping for... I guess another possibility would be to have two arguments, one for integers and one for pointers: lo_address_set_option(a, LO_ADDRESS_SLIP, 1, 0); where the last argument is reserved for future use as a string or struct pointer. Any opinions? Alternatively maybe this is putting the cart before the horse, but I'd rather not be stuck with yet more inflexible functions. In retrospect we could have used such an API for setting the multicast TTL and interface, for example, instead of having special lo_server constructors and special functions for those cases. (Another point of view is that having lots of dedicated functions is a good thing since it allows capabilities to be easily detected by autotools...) Steve |