Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

classic Classic list List threaded Threaded
135 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Marco van de Voort
On Sun, Jan 02, 2011 at 11:22:43PM +0200, Graeme Geldenhuys wrote:
> > The type name might come from Delphi compatibility (tada!).
>
> And once again for someone as myself, not using Delphi, it is quite
> ridiculous too see the errors the Free Pascal project makes

It doesn't. You just assume nobody thought about it before you, and that it
is an error. Moreover, you also assume that everybody has the same
sensitivities as you about certain topics, and again that is wrong.

> (or should that rather be the errors Delphi makes) in such cases/examples.
> Trying to fool all developers into thinking that "unicode" [as in
> UnicodeString type] only means UTF-16, because indecently that is what
> Microsoft uses in its Windows OS.

We would never try to "fool" anybody to think such a thing. Please stop
putting words in our mouths.

> Maybe the code-page enabled string type (cpstrnew branch) will use
> some more "sane" name for its string type, or redefine the standard
> String type to mean a code page / encoding enabled string type instead
> of String = AnsiString.

This is all undecided. I lean towards splitting operating system targets
into a utf8 and a utf16 one for most platforms(*), since nobody will ever agree
on one encoding.  Not even per platform.

(*) and a legacy "ansi" one if need be.
 
> > And currently UTF8String is defined as AnsiString, so there is currently no
> > difference
>
> That's what I thought. So why did they [FPC team] actually bother to
> create the UTF8String type then?

It's an alias for literal programming purposes. You can see from the
typename what a procedure expects, and it goes into the documentation

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Michael Schnell
On 02/12/2011 06:49 PM, Marco van de Voort wrote:And currently
UTF8String is defined as AnsiString, so there is currently no
>>> difference
>> That's what I thought. So why did they [FPC team] actually bother to
>> create the UTF8String type then?
> It's an alias for literal programming purposes.

While I disagree on much of his wording I so agree with the OP, that
with having ANSIString and UTF8String an alias for exactly the same -
only to allow for keeping in mind what coding the user manually
introduces - is very confusing. These names strongly suggest that a
statement myANSIString :=  MYUTF8String either is detected as illegal or
forces appropriate conversion.

-Michael

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Felipe Monteiro de Carvalho
In reply to this post by Marco van de Voort
On Sat, Feb 12, 2011 at 6:49 PM, Marco van de Voort <[hidden email]> wrote:
> This is all undecided. I lean towards splitting operating system targets
> into a utf8 and a utf16 one for most platforms(*), since nobody will ever agree
> on one encoding.  Not even per platform.
>
> (*) and a legacy "ansi" one if need be.

Why do we need "targets"?

Wouldn't it be better to simply duplicate all string functions for
utf8 and utf16 and ansi if necessary?

That was my idea from the start in case the new string was merged. For example:

CompareText
UTF8CompareText
UTF16CompareText

The versions with a fixed encoding could refer to a generic unicode
version with undefined encoding.

--
Felipe Monteiro de Carvalho

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Graeme Geldenhuys
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/


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Felipe Monteiro de Carvalho
On Mon, Feb 14, 2011 at 1:08 PM, Graeme Geldenhuys
<[hidden email]> wrote:
> But that doesn't limit the developer, because the developer could simply
> define a new string type and use that instead.

Maybe I used a bad example, but anyway, var parameters need to be exact

> So for every possible encoding and code page you want to make a new
> function?

Of course not! Only the important ones. For me this means only UTF-8,
but I supposed some people might want UTF-16 too.

--
Felipe Monteiro de Carvalho

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Graeme Geldenhuys
Op 2011-02-14 14:15, Felipe Monteiro de Carvalho het geskryf:
>
> Maybe I used a bad example, but anyway, var parameters need to be exact

"alias types" are not really new types, so will not affect var
parameters. So in my previous example, UTF16String will still be a
UnicodeString. The only difference will be that UTF16String has its
internal encoding bit set to UTF-16.

Here is a test program using latest FPC 2.4.3 showing that TMyString =
String - the compiler sees no difference between the two types. So the
same should be valid for UnicodeString vs UnicodeString(...) that have
their encoding bit set to something other than the platform default.

---8<-----------8<-----------8<-----------8<-----------8<-----------
program project1;

{$mode objfpc}{$H+}

uses
  Classes

type
  TMyText = String;

procedure TestMe(var AText: string);
begin
  writeln(AText);
  AText := 'Hello ' + AText;
end;

var
  s: TMyText;

begin
  s := 'Graeme';
  TestMe(s);
  writeln(s);
end.
---8<-----------8<-----------8<-----------8<-----------8<-----------



>> So for every possible encoding and code page you want to make a new
>> function?
>
> Of course not! Only the important ones. For me this means only UTF-8,
> but I supposed some people might want UTF-16 too.

Again I don't see why that is needed. You might only require UTF-8, but
somebody else wants UTF-16, and somebody else wants CP850 versions etc
etc.. Where does it end?

A simple function like:

  function CompareText(const S1: UnicodeString;
                       const S2: UnicodeString): integer;

should be able to work with any UnicodeString parameters (including
alias types that have different encoding bits set). So it should work
fine for your UTF-8 text, and somebody else's UTF-16 etc. text.


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Felipe Monteiro de Carvalho
On Mon, Feb 14, 2011 at 2:35 PM, Graeme Geldenhuys
<[hidden email]> wrote:
> Here is a test program using latest FPC 2.4.3 showing that TMyString =
> String - the compiler sees no difference between the two types. So the
> same should be valid for UnicodeString vs UnicodeString(...) that have
> their encoding bit set to something other than the platform default.

It is pure speculation to assume that this behavior will remain valid.

--
Felipe Monteiro de Carvalho

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Graeme Geldenhuys
Op 2011-02-14 16:00, Felipe Monteiro de Carvalho het geskryf:
>
> It is pure speculation to assume that this behavior will remain valid.

Well, it seems obvious to me that it should [and would]. From my
previous examples, the alias type is still a UnicodeString type. So why
wouldn't methods/procedures/functions that take UnicodeString types as
parameters work?

If the FPC implementation of such a UnicodeString (and the baviour I
described) cannot handle such cases, then I would have to say that the
FPC implementation would be seriously crippled. Lets hope it doesn't go
that route.

Not that I care (because Delphi doesn't do everything perfect), but how
does Delphi 2010 handle such alias types - especially when passed as
parameters (var and const)?


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Jürgen Hestermann
In reply to this post by Graeme Geldenhuys
Graeme Geldenhuys schrieb:
 > A simple function like:
 >   function CompareText(const S1: UnicodeString;
 >                        const S2: UnicodeString): integer;
 > should be able to work with any UnicodeString parameters (including
 > alias types that have different encoding bits set). So it should work
 > fine for your UTF-8 text, and somebody else's UTF-16 etc. text.

Do you mean that the compiler should convert the strings as needed in
the background (as between different integer types and/or floats) so
that you can call ListBox1.Items.Add(x) with x beeing UTF8string or
UTF16string or...? I am not sure whether this is a good idea because the
programmer no longer knows how many conversions take place and therefore
cannot judge the performance impact anymore. On the other hand it would
make the life easier for beginners.


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

José Mejuto
Hello Lazarus-List,

Monday, February 14, 2011, 7:03:31 PM, you wrote:

JH> Do you mean that the compiler should convert the strings as needed in
JH> the background (as between different integer types and/or floats) so
JH> that you can call ListBox1.Items.Add(x) with x beeing UTF8string or
JH> UTF16string or...? I am not sure whether this is a good idea because the
JH> programmer no longer knows how many conversions take place and therefore
JH> cannot judge the performance impact anymore. On the other hand it would
JH> make the life easier for beginners.

I'm unable to see the "great" problems with "UnicodeString". The
conversions should be the minimun needed, and they will be. Problem
would be in the RTL, but not at user level. You say that the
programmer will not know how many conversions take place, that's
right, but I think they are garanteed to be the minimum except in some
corner cases like "CompareText(UTF8String,WideString)" as one of both
must be converted, but whichever one, could be a fixed situation or
platform dependent, I do not know.

Many people are concerned about "speed" due hidden conversions, so can
anybody tell me why ? Maybe I'm blind and I can not see something that
is absolutly a problem (except some pieces of RTL).

--
Best regards,
 José


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Mattias Gaertner
On Mon, 14 Feb 2011 20:13:45 +0100
José Mejuto <[hidden email]> wrote:

> Hello Lazarus-List,
>
> Monday, February 14, 2011, 7:03:31 PM, you wrote:
>
> JH> Do you mean that the compiler should convert the strings as needed in
> JH> the background (as between different integer types and/or floats) so
> JH> that you can call ListBox1.Items.Add(x) with x beeing UTF8string or
> JH> UTF16string or...? I am not sure whether this is a good idea because the
> JH> programmer no longer knows how many conversions take place and therefore
> JH> cannot judge the performance impact anymore. On the other hand it would
> JH> make the life easier for beginners.
>
> I'm unable to see the "great" problems with "UnicodeString". The
> conversions should be the minimun needed, and they will be. Problem
> would be in the RTL, but not at user level.

Yes, since for example Linux allows non valid UTF-8 as file names,
so any auto conversion of file names to UTF-16 is an error.


>  You say that the
> programmer will not know how many conversions take place, that's
> right, but I think they are garanteed to be the minimum except in some
> corner cases like "CompareText(UTF8String,WideString)" as one of both
> must be converted, but whichever one, could be a fixed situation or
> platform dependent, I do not know.
>
> Many people are concerned about "speed" due hidden conversions, so can
> anybody tell me why ? Maybe I'm blind and I can not see something that
> is absolutly a problem (except some pieces of RTL).

For instance searching needs a lot of compares. Comparing two
strings normally fails on the very first characters. An auto conversion
will always convert the whole string including allocating and releasing
memory, easily slowing down the conversion by an order of magnitude.

Mattias
 

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Marco van de Voort
In reply to this post by José Mejuto
On Mon, Feb 14, 2011 at 08:13:45PM +0100, Jos? Mejuto wrote:
> Many people are concerned about "speed" due hidden conversions, so can
> anybody tell me why ? Maybe I'm blind and I can not see something that
> is absolutly a problem (except some pieces of RTL).

Typical example is you mix two codebases which have a different opinion
about the string type. Then for every transition between those two codebases
you have a fair chance that a conversion is needed. It is throughout
possible that if you do an Tstringlist.indexof() that you do as many
conversions as elements in the stringlist (if your passed stringtype is
different from the tstringlist one).

A minimum conversion scheme uses one type internally and only converts at
the bounderies of the system. But even that has worst cases, e.g. like
operating on  large database exports in a different format than native.

But at least that kind of problems is fairly localised. It is harder if it
is everywhere in the codebase, like the former example.



--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

José Mejuto
In reply to this post by Mattias Gaertner
Hello Lazarus-List,

Monday, February 14, 2011, 8:29:04 PM, you wrote:

>> I'm unable to see the "great" problems with "UnicodeString". The
>> conversions should be the minimun needed, and they will be. Problem
>> would be in the RTL, but not at user level.
MG> Yes, since for example Linux allows non valid UTF-8 as file names,
MG> so any auto conversion of file names to UTF-16 is an error.

Hmmm... To me it looks like a Linux "problem"/"bug" for that kind of
access it is logical to me to use low level APIs. OK, that way you can
not access those files ? yes, but also in Windows there are similar
problems, some files can not be accessed using regular APIs and some
tricks must be used.

>> Many people are concerned about "speed" due hidden conversions, so can
>> anybody tell me why ? Maybe I'm blind and I can not see something that
>> is absolutly a problem (except some pieces of RTL).
MG> For instance searching needs a lot of compares. Comparing two
MG> strings normally fails on the very first characters. An auto conversion
MG> will always convert the whole string including allocating and releasing
MG> memory, easily slowing down the conversion by an order of magnitude.

This are the "some corner cases" which can not be handled in the usual
conversion, operation, conversion back, but I think there are not much
cases like this. Of course, there are cases like a TStringList with
100000 items in UTF16 and perform a search using an UTF8String, so or
a conversion request to the stringlist (convert all elements in one
go) or you must use your unicodestring using default unicode format
for the platform.

I would like to see an example of such problem (snippet) which could
be a headache, but maybe in the fpc mailing lists ?

--
Best regards,
 José


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

José Mejuto
In reply to this post by Marco van de Voort
Hello Lazarus-List,

Monday, February 14, 2011, 8:52:27 PM, you wrote:

>> Many people are concerned about "speed" due hidden conversions, so can
>> anybody tell me why ? Maybe I'm blind and I can not see something that
>> is absolutly a problem (except some pieces of RTL).
MvdV> Typical example is you mix two codebases which have a different opinion
MvdV> about the string type. Then for every transition between those two codebases
MvdV> you have a fair chance that a conversion is needed. It is throughout
MvdV> possible that if you do an Tstringlist.indexof() that you do as many
MvdV> conversions as elements in the stringlist (if your passed stringtype is
MvdV> different from the tstringlist one).

But you are in the same trouble if you use any other approach, or you
use your data in the same unicode format as the other codebase or you
update the codebase to use your "new" unicode format.

There isn't a solution for such situation. I'm currently working with
GeckoPort which uses WideString in every place and other special
strings. I know that conversions must happend so when I need to scan
for a string first convert my data to the "native" format and them
perform the scan.

I think expecting a TStringList in ansi encode to work transparently
and optimal using unicodestrings is just a dream, programmers should
update their codebase, but at least only for speed (reduce
autoconversions) and do not need to decide constantly which encoding
format is needed to call this or that function.

Using a different RTL for each encoding is even worst IMHO. But this
is just a simple opinion.

--
Best regards,
 José


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Graeme Geldenhuys
In reply to this post by Jürgen Hestermann
Op 2011-02-14 20:03, Jürgen Hestermann het geskryf:
> Do you mean that the compiler should convert the strings as needed in
> the background (as between different integer types and/or floats) so
> that you can call ListBox1.Items.Add(x) with x beeing UTF8string or
> UTF16string or...?

Yes, but in reality how often would such conversions happen? TStringList
(used inside a TListBox) would use UnicodeString types. The encoding of
that type would default to whatever platform you compiled on. ie: under
Linux it would default to UTF-8, and under Windows it would default to
UTF-16

So if you define a new string of UnicodeString type in code, it would
automatically match the encoding type of the TStringList, so when you
add a string item to the listbox, no conversion would be needed. This
would probably be the case 99% of the time.

The developer would physically have to create a new string with and
manually set an encoding different to the platform default, before a
auto-conversion would be required.

In day-to-day work and in most cases auto-conversions will be kept to a
minimum - automatically.


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Graeme Geldenhuys
In reply to this post by José Mejuto
Op 2011-02-14 21:13, José Mejuto het geskryf:
> right, but I think they are garanteed to be the minimum except in some
> corner cases like "CompareText(UTF8String,WideString)" as one of both
> must be converted, but whichever one,


Exactly, auto-conversion would be kept to a minimum without any user
intervention. In the above example CompareText() could quickly check
each strings encoding, and if one matches the platform default, that
string doesn't need a conversion.

So in your example above, if you ran that under Linux, only the second
parameter would require an encoding conversion.


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Hans-Peter Diettrich
In reply to this post by Graeme Geldenhuys
Graeme Geldenhuys schrieb:

> Op 2011-02-14 20:03, Jürgen Hestermann het geskryf:
>> Do you mean that the compiler should convert the strings as needed in
>> the background (as between different integer types and/or floats) so
>> that you can call ListBox1.Items.Add(x) with x beeing UTF8string or
>> UTF16string or...?
>
> Yes, but in reality how often would such conversions happen? TStringList
> (used inside a TListBox) would use UnicodeString types. The encoding of
> that type would default to whatever platform you compiled on. ie: under
> Linux it would default to UTF-8, and under Windows it would default to
> UTF-16

You realize the problems, that may result from the different char type
of such an target-specific string type?

IMO such strings should be encapsulated in a (polymorphic) class, that
only allows for char-type independent operations.

DoDi


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Marco van de Voort
In reply to this post by Graeme Geldenhuys
On Tue, Feb 15, 2011 at 08:50:49AM +0200, Graeme Geldenhuys wrote:
>
> Yes, but in reality how often would such conversions happen?

Does that really matter? If I don't now beforehand that I can control such issues
with some strategic choices, I won't start using it at all.


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

Sven Barth
In reply to this post by Graeme Geldenhuys
Am 14.02.2011 15:23, schrieb Graeme Geldenhuys:
> Not that I care (because Delphi doesn't do everything perfect), but how
> does Delphi 2010 handle such alias types - especially when passed as
> parameters (var and const)?

In Delphi such strings with codepage need to be defined with "type" and
thus they are different types (not compatible regarding "var").

The following example fails to compile at the call of Test.

====source begin====
program strvartest;

{$APPTYPE CONSOLE}

uses
   SysUtils;

type
   CyrillicString = type AnsiString(1251);
   LatinString = type AnsiString(1252);

procedure Test(var aStr: CyrillicString);
begin

end;

var
   s: LatinString;
begin
   s := 'Foo';
   Test(s);
end.
====source end====

Regards,
Sven

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?

José Mejuto
In reply to this post by José Mejuto
Hello Lazarus-List,

Tuesday, February 15, 2011, 4:27:40 PM, you wrote:

MvdV> There is a solution that you can take FPC and Lazarus libraries out of the
MvdV> equation by splitting each target into an one and two byte encoding
MvdV> platform. That should fix the bulk of the problem.
[...]
MvdV> Update to what? The point is that neither of both most used encodings (UTF8/16) is
MvdV> is going away anything soon, and the split is right through platforms.

So you are talking about a "platform" about the encoding, but in any
operative system platform, this means you can choose RTL Linux 32 bits
WideString or RTL Linux 32 bits UTF8, do not ?

>> Using a different RTL for each encoding is even worst IMHO. But this
>> is just a simple opinion.
MvdV> Let's here the argumentation for that then.

Well, maybe I misunderstood the platform split...

--
Best regards,
 José


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
1234 ... 7