by Michael S. Kaplan, published on 2005/05/29 02:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/05/29/422980.aspx
A little over a month ago, I was talking about how SetLocaleInfo really stinks. Buried in my tirade was the germ of a question that people have asked in the past -- why is there no setting analogue to the LOCALE_RETURN_NUMBER flag used by functions like GetLocaleInfo, a sort of LOCALE_SPECIFY_NUMBER flag for the numeric fields? They are all small integers, so there is a simple enough method and datatype for such a flag to use.
Of course that is kind of syntactic sugar for SetLocaleInfo. The functions where the problem looks worse for us are GetCurrencyFormat and GetNumberFormat. They both have the following text for their lpValue parameters:
lpValue
[in] Pointer to a null-terminated string containing the number string to format.
This string can contain only the following characters:
- Characters '0' through '9'.
- One decimal point (dot) if the number is a floating-point value.
- A minus sign in the first character position if the number is a negative value.
All other characters are invalid. The function returns an error if the string pointed to by lpValue deviates from these rules.
So not only is there no way to pass an actual number to these functions (you must pass a string), but you also have to use a simple string that is not even vaguely internationally wise. It is not even a good US string, since you would have to pass long numbers without grouping separators, something that is very un-natural. Yuck!
But if you think about it, this does make sense. Would you want a function that would accept input one moment and then potentially fail with that same input moments later after a change to settings? Not to mention the performance impact of having to insert complex parsing logic into the function based on those settings, giving developers a very difficult to debug problem in the most common cases.
Of course one could expect that the function could use the same format as is expected in the locale passed in, but if the developer was able to format a string with that locale's settings, she would not need the function, right?
Now the fact that there is no LOCALE_SPECIFY_NUMBER type flag to pass is a bit stranger since it's not like this function gives the benefits of passing a string, right?
But before you agree with my strawman question, consider for a moment what datatype you would use.
Both functions will accept outrageously large numbers, much larger than any common C-style type that is available under Windows. And both will accept fractional values that are 100% precise -- way more precise than any floating point type that is available. You can start imagining complex schemes with different flags for different types of numbers, I suppose. And all that work and the functions would become hideously complex for customers to call and for us to maintain, all to provide less functionality than the current simple string allows!
Sometimes the simple answers are the best ones. If you ask me, both GetCurrencyFormat and GetNumberFormat fall in that category, and on the whole I am happy with how these funcions work....
This post brought to you by "Z" (U+005a, LATIN CAPITAL LETTER Z)
(All of the other letters were still asleep, and when they were saying Zzzzzzz, the Z woke up, thinking someone was calling her name!)
# Mihai on 29 May 2005 5:56 PM:
# Michael S. Kaplan on 29 May 2005 6:23 PM:
# John Bates on 5 Jun 2005 7:40 PM:
referenced by