[Lazarus] Does Lazarus support a complete Unicode Component Library?
Graeme Geldenhuys
graemeg.lists at gmail.com
Mon Feb 14 13:08:10 CET 2011
Op 2011-02-14 13:16, Felipe Monteiro de Carvalho het geskryf:
>
> Why do we need "targets"?
I would imagine that such a new string type (possibly UnicodeString)
would default to the encoding used per platform by default.
eg:
* a Linux UnicodeString will default to UnicodeString(utf8)
* a Windows UnicodeString will default to UnicodeString(utf16)
etc..
But that doesn't limit the developer, because the developer could simply
define a new string type and use that instead.
eg:
// alias types with their encodings set to something specific
UTF8String = UnicodeString(utf8);
UTF16String = UnicodeString(utf16);
CP850String = UnicodeString(cp850);
etc...
> Wouldn't it be better to simply duplicate all string functions for
> utf8 and utf16 and ansi if necessary?
Why? CompareText and all other such functions should simply take a
UnicodeString types as parameter (in addition to the already existing
WideString, AnsiString and ShortString versions). The Unicode enabled
version of CompareText will then query the encodings used and do a
automatic conversion if needed, then do the comparison and return the
result.
eg:
var
u8: UTF8String;
u16: UTF16String;
s850: CP850String;
r: integer;
begin
u8 := ...;
u16 := ...;
s850 := ...;
r := CompareText(u8, u16);
...
r := CompareText(u8, s850);
...
end;
> CompareText
> UTF8CompareText
> UTF16CompareText
So for every possible encoding and code page you want to make a new
function? That doesn't sound like a good plan to me. The encoding
information is inside the string type, so use it to do automatic
conversions.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
More information about the Lazarus
mailing list