aboutsummaryrefslogtreecommitdiff
path: root/src/unit/archive.unit
diff options
context:
space:
mode:
authorMike Buland <eichlan@xagasoft.com>2010-11-19 05:54:14 +0000
committerMike Buland <eichlan@xagasoft.com>2010-11-19 05:54:14 +0000
commit7c335ede527eaf4a3053ef35b1299141d34aaf40 (patch)
tree5ececc9181090cce540a5e4fbe28eda97e4e5c2b /src/unit/archive.unit
parent2fe32ba19571ff775a55f61eca355a46f269393e (diff)
downloadlibbu++-7c335ede527eaf4a3053ef35b1299141d34aaf40.tar.gz
libbu++-7c335ede527eaf4a3053ef35b1299141d34aaf40.tar.bz2
libbu++-7c335ede527eaf4a3053ef35b1299141d34aaf40.tar.xz
libbu++-7c335ede527eaf4a3053ef35b1299141d34aaf40.zip
I now think that this may not work out at all. It looks like if we want proper
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.
Diffstat (limited to 'src/unit/archive.unit')
0 files changed, 0 insertions, 0 deletions