[fpc-devel] String and UnicodeString and UTF8String
Marco van de Voort
marcov at stack.nl
Wed Jan 12 07:45:47 CET 2011
In our previous episode, Jeff Wormsley said:
> > encoding of full Unicode. Ansi and UCS2 (really UTF-16) only *look*
> > easier to handle in user code, but both will fail and require special
> > code whenever characters outside the assumed codepage may occur.
> Preface: I don't write international apps, and probably won't for the
> foreseeable future...
> Isn't all of this concentration on trying to make strings have single
> byte characters (who cares how they are encoded), using the argument
> that it is somehow faster, incorrect for just about any modern
> processor, including embedded CPU's such as ARM?
> It was my
> understanding that 32 bit aligned access was always faster than byte
> aligned access on just about any CPU FPC still supports.
1-byte access is always 1-byte aligned, and the memory system is still
slower than these kind of issues. And you shuffle a lot of zeroes extra
But the trouble is also that 2-byte situation doesn't really solve anything,
(you still have surrogates and it never will be as simple as it was), and a
much bigger problem with legacy (how many two byte data do you get daily,
and how much 1 byte?)
> The argument holds just fine for memory, but I don't really get the
> speed argument. Maybe I'm missing something.
Shoveling twice as much memory around IS the speed argument :-)
More information about the fpc-devel