Re: Glib::ustring's operator<< doing a conversion to locale, why?

["Milosz Derezynski" <internalerror gmail com>]

Hey everyone again,

The issue still sticks with us in our code, and here is one thing i could quite get the hang of what Chris said, because i did _not_ mention numbers specifically:

On 5/4/07, Chris Vine <chris cvine freeserve co uk> wrote:

You
mention numbers, but they are not a problem as in ASCII/UTF-8 they have
a single byte representation.

but i got now  that what he meant were my references to boost::format.

Well let me just lay down here that we are using boost::format _heavily_ for SQL queries, which don't contain only nubmers, and it forces us to use ::raw()/::c_str() _every time_ we use it.

It's just one more thing we didn't cause, we have to watch out for, and have to _closely_ watch out for or things will get into a real mess wrt UTF-8 and other locales (we're using an sqlite UTF-8 database and are getting our metadata from gstreamer and taglib in UTF-8 and store it as such always).

So this said, this isn't about numbers, nor is it about width formatting, it's plainly about having to do a workaround for something that was once thought as being good, but which seems to turn out to be bad more and more.

Guys Boost is going to get just more popular, not less, and it's not the only case where operator>>() and operator<<() are used implicitly. They are not only in use with sstream and cerr/cout. Please rethink this; we know it would be a huge internals/API break, but i'd advocate at this point late than never.

-- Milosz