[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