Artyom wrote:
There are two problems:
1. Every medium size C++ project uses C libraries. And they will always be there. 2. When C++ locale's system is quite broken in its current state and useless for most of users then you can't expect them to be aware of such issues.
The other problem is that I hear complains about it too frequently:
- libdbi mailing list is full of it and there is open bug - SOCI has issues - The problem with lexical cast rise once in a while in Boost's list.
No, if something causes bugs too frequently then there is something wrong with the concept.
Artyom
So your design wrt. this is: nothing is localized unless explicitly requested to. That avoids having something accidentally localized when you don't want that, e.g. csv, serialization, some network protocol, whatever. But that is at the expense of making a way for the opposite kind of bugs: when something is not localized but should be. For example what does 02/03/2011 mean. Imagine a program where all dates in other places that are shown to the user are properly localized, but this one isn't due to a programmer omission. The result is, well, a very angry user with all its consequences. I'm not going to argue which one is more important. We lose something either way. And this concern is what the reviewers had in mind when they brought the issue up in this thread. In this respect yes, C++ standard library has design issue, but Boost.Locale has one too. It's a design choice, which happens to be different between C++ std lib and your lib. And I have no problem with that. But the documentation can discuss this issue in detail, describe common traps and the ways to avoid them. It can also have a general advice: if you want to localize your software, pay extra attention to what you want to be localized and what you don't. Gevorg