On Mon, 7 Feb 2005 21:23:36 +0100, Yann Dirson wrote: > Looking around a bit, I found that glibc provides a set of functions > to specify in which language we want the number to be parsed. > > So instead of using atof() we can use strtof_l() if available.
What is that supposed to be? It is neither in my copy of the C99 standard nor in the latest draft of the C standard. A glibc invention? On my Debian, there isn't even a manpage for it, so I can only guess what it does based on its signature. I'm not really eager to use a function "*not* standardized in any form" and described as "a proof-of-concept implementation" (the emphasis is not mine, these quotes are directly taken from the header file). > No objection to check for the availability of this function, and only > if not, then revert to the setlocale()-based workaround ? Objections. First, why implement two mechanisms when a single one is enough? Second, there is a lot more than just atof and strtoxx. You also need to take into account xxprintf (a lot of them all around the place), C++ stream inputting (lexical_cast and so on), and C++ stream outputting (AI values are saved in the savegame files for example). At least setlocale takes care of them all, without having to review each one of them to see if it deals with floating-point value and then correct it if it must be locale independent. > Was there any specific reason to use atoxx() rather than strtoxx(), > appart for them to be more concise ? I note that there are indeed a > couple of calls to strtoul(), so I guess it is not a portability > issue. What's wrong with concision? I don't know why they are here in the first, but since atof is strictly equivalent to strtod (except for the behavior on error, as mandated by the standard), why not use it? It's not like we want to test errno or the end pointer after each conversion anyway, so better use the shortest form. > Consistently using strto*_l(), #defined to their standard > strto*() counterparts when not available, would provide an easy way to > handle this. Sorry, you have lost me here. An "easy way" to handle what? You didn't explain the problem you are trying to solve here, so I can't really say if your solution is fine or not. Regards, Guillaume
