[fpc-devel] Unicode resource strings

[Hans-Peter Diettrich]

Graeme Geldenhuys schrieb:
> On 22 August 2012 00:54, Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:
>> IMO string conversion and CRC are mutually exclusive.
> 
> Accessing a 100k of files (filenames to be exact) in a UTF-8
> environment (Linux), which must all be stored in a UTF-16 string type.

Filenames typically deserve platform specific handling, so that a 
special type and related classes (TFileNameList?) may be a good idea.

TFileName already exists BTW. It might be a good idea to also *use* it 
in the RTL/LCL filehandling support.

> That's lots and lots of encoding conversions right there - in a tight
> loop.

Well, what do you intend to do with the filename list? Reading the files 
certainly requires more time than the conversions of the filenames.

>  The point is, your apps might not require lots of encoding
> conversions, but there are lots of different types of apps out there -
> it all depends on what the application does.

When I look at the Unicode introduction in VB4 and Delphi, there was 
much rumor before, many people expected slow programs with high memory 
requirements. Half a year later the move was accepted, and nobody 
complained any more. I don't think that this will be different for 
FPC/Lazarus :-)

BTW VB4 offered both an 16 bit (Ansi) and 32 bit (Unicode) compiler, so 
that everybody could evaluate and compare both versions. It turned out 
that the 32 bit Unicode versions at least were not slower than the 16 
bit Ansi versions. VB5 came with 32 bit support only, and nobody asked 
for an Ansi version any more.

FPC could go the same route, offering the old (Ansi/UTF-8) version in 
parallel to a new Unicode (UTF-16) version. This step is required 
anyway. Then everybody can find out the real pro's and con's, and 
whether it's really recommended to continue supporting both versions.

DoDi