Age | Commit message (Collapse) | Author | |
---|---|---|---|
2011-03-22 | We now have a UTF-8 test parser, I'm going to move it into a functor, I think. | Mike Buland | |
2011-03-18 | Wow, a lot has changed. String is not a template class, and it can do it's own | Mike Buland | |
formatting ala QString. | |||
2011-01-20 | Made (very) basic progress towards defining UtfString. It's actually going to | Mike Buland | |
use a Bu::String as it's backend storage, so we'll get all the great out of that... | |||
2011-01-20 | Wow, got the Stream changes propegated, all tests build with string instead of | Mike Buland | |
fstring, and updated the copyright notice to extend to 2011 | |||
2011-01-20 | Bu::FString is now String, and there's a shell script to fix any other programs | Mike Buland | |
that were using fstring, I hope. | |||
2010-11-19 | I now think that this may not work out at all. It looks like if we want proper | Mike Buland | |
Unicode handling we'll need to implement a series of codecs and converters as well as tables of codepages and lookups. It'll be interesting, I guess, but it makes me care a lot less about proper encoding. Anyway, UtfString uses shorts instead of chars, so it's a step in the right direction, but still not enough to be able to handle proper UTF-16 encoding, maybe UCS-2 encoding, but... ...that's lame. Bu::FBasicString has been generalized a bit with optimizations from libc for char based strings. It also, unfortunately, still uses char-only functions in several places, those all rely on char casting strings at the moment just to get the thing to compile. Basically, it's not a good UTF-16 solution yet, and it may never be and remain compatible with char based strings. |