[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 mailing list