[Openmcl-devel] Plans for Unicode support within OpenMCL?
keke at gol.com
Tue Mar 21 18:47:56 PST 2006
Pat Lasswell wrote:
> > If having multiple string types is not desirable, I think UTF-16
> > string is a good compromise. The 4-fold increase of string size
> > is too much.
> A 4-fold increase is too much? While I don't advocate that the
> hardware requirements of OpenMCL keep up with Moore's Law, it seems
> that bits and flops are so cheap that a little extra string storage
> isn't going to be noticed in amonst the mp3s and jpegs.
I don't think "a little extra string storage" is an accurate
description. It's 4x increase of what you have.
Say you read 100k ascii (or latine-1) text file into buffer,
the buffer needs to be 400k in size (if the string is 32-bit).
If input is 1000k, the buffer will be 4000k. and so on.
I believe that having multiple string types is better.
(If Moore's Law also applies to processor speed, then we can
perhaps ignore a little bit of extra cpu cycles?)
MCL has extended-string which is 16-bit and I like it. I like
it perhaps because I have never cared how it is implemented.
And crucially, Gary doesn't like it (or doesn't seem
enthusiastic about it.)
More information about the Openmcl-devel