All in all Graeme is right. FPC looks pretty much broken to me, too.
For my projects I pulled the emergency-break on anything FPC.
The most serious flaws for me of FPC 3.0 are:
- assuming that it's possible to assign an encoding to every string
- using an (unsafe) guess about the encoding for auto-conversions
It's not possible to assign a valid encoding to every string (not automatically, and not even manually).
Some examples:
1) String-Buffers
Split a UTF-8 String into chunks of 1024 bytes. Trying to assign an encoding to
those chunks, and allowing auto-conversions will just lead to corruption.
Where is the string-type for string-buffers gone?
2) Most programming languages out there use something like "sequence of UTF-16 codepoints" as a string-type.
(That's not the same as UTF-16 string !!!!!)
It's a proper string type for "UTF-16 buffer" - pretty much nobody out there uses a low-level string-type that assumes
that the content is a complete UTF-16 string.
You can't convert any random filename on Windows to UTF8 and back without dataloss.
There simply isn't any encoding that correctly fits to all possible filenames.
A lot of APIs use buffers. You can try to assign an encoding to a buffer, but if you use that encoding
to auto-convert anything you made a blatant mistake. Assuming that anything from the outside world
(WindowsAPI, C#, Java...) is UTF-16 is yet another blatant mistake...
4) some Barcodes,
5) Various File-Format-Standards,
6) anything that uses ASCII + some Control-Bytes for communication,
7) some encodings used in databases, ...
all that won't fit into the FCP scheme of 'known encodings'..
The most obvious showstoppers for FPC 3.0 are:
FPC 3.0 doesn't have a useful type for string-buffers.
FPC 3.0 doesn't have a useful type for Filenames
FPC 3.0 adds unsafe auto-conversions
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
