Graeme Geldenhuys schrieb:
On 22 August 2012 00:54, Hans-Peter Diettrich <drdiettri...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
