On 2013.05.29 13:01, Ludovic Rousseau wrote: >> Why not go: >> const char * LIBUSB_CALL libusb_strerror(enum libusb_error errcode, >> const char *locale); >> ? > > Because very few people will need to change the locale parameter for > different calls to libusb_strerror()?
That wasn't the point. The point was to be KISS and reduce the complexity we need to add for the localization of less than 20 error messages, i.e. "if you want localization, we will provide it to you, but don't expect us to invest on a full blown implementation, when we have only 20 messages to localize" > Because it is adding complexity to the API comprehension? I disagree. IMO It's a lot more explicit and intuitive to have everything related to localization in a single call. No need for a dev to ponder "wait, did I call xyz_setlocale() with the right parameter?" or, as the rest of this thread is highlighting, "Should I expect libusbx to detect my locale?". As I said, can't be any more KISS and explicit about what our call does than that. > Because the API will not look like the ISO C99 strerror(3) function any more? Now, that is a valid point. But then again, I'm concerned about the "possibly using the LC_MESSAGES part of the current locale to select the appropriate language" part of the POSIX implementation [1]. Does that mean that, if we want to conform to the expected strerror() implementation, we have to add LC_MESSAGES detection for all platforms, even those, like Windows, where LC_MESSAGES isn't really the native way of setting the locale for messages and where it may very well be undefined (see my next mail)? Regards, /Pete [1] http://linux.die.net/man/3/strerror ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
