Re: [fpc-pascal] Re: Strings - suggestions

[Michael Van Canneyt]

On Sat, 22 Dec 2012, Reinier Olislagers wrote:




On 22-12-2012 12:55, Michael Van Canneyt wrote:

On Sat, 22 Dec 2012, dev.dliw-re5jqeeqqe8avxtiumw...@public.gmane.org
wrote:


Hi,
concerning the string topic, for me (using fpc since 2.0.4 on a
regular basis;
TP experience ~ average user) there really should be an decision what
way to
go as early as possible.


- We'll implement the capacity to have a code-page aware string type, as
Delphi has.
  (well, it is there already).

- The {$H } directive will be extended so you can choose which string
type you need per unit.
  (ansi/wide/utf16/utf8...)
  This is different from Delphi, where you don't have this choice:
String=Widestring.

So how would the patch in e.g.
http://bugs.freepascal.org/view.php?id=22095
fit in?


It will need to be adapted if you want to avoid conversions.

It already does lots of conversions anyway as soon as a unicode ODBC is 
detected.
basically, it just switches to the unicode version and does all conversions in 
the background...


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Strings - suggestions

[Reinier Olislagers]

On 24-12-2012 12:01, Michael Van Canneyt wrote:
> On Sat, 22 Dec 2012, Reinier Olislagers wrote:
>> On 22-12-2012 12:55, Michael Van Canneyt wrote:
>>>   This is different from Delphi, where you don't have this choice:
>>> String=Widestring.
>> So how would the patch in e.g.
>> http://bugs.freepascal.org/view.php?id=22095
>> fit in?
> 
> It will need to be adapted if you want to avoid conversions.
> 
> It already does lots of conversions anyway as soon as a unicode ODBC is
> detected.
> basically, it just switches to the unicode version and does all
> conversions in the background...

Yes, of course.
The thing is that you need to have some kind of architecture/plan of how
unicode support is to be set up, which types are allowed etc if you want
to adapt the code.
That was what I was getting at.

IIRC, the odbc patch was written as a pilot/learning by doing approach
(AFAIR: we need national character support - for ANSI as well - for
this, odbc requires the *w variants of the API calls for that, but that
is incidental).
Next up would be to see how the integration with the RTL could/should be
done, but obviously this next step has not been taken.

Well, anyway, I myself am not in a rush, but I think it may be in the
interest of FPC to communicate clearly[1] when/if a decision has been
reached as well as its status (e.g. we're working on implementation and
this may still change depending on our experiences or we've been working
on this for a while and these specific contributions are more than welcome).
Updating that wiki article seems like a good way to keep this easily
findable as well as updated as time goes by.

This way, perhaps the amount/frequency of suggestions on implementing
unicode support can be lessened and more energy can be put into getting
the desired support working - not only by core fpc members but also
general contributors.

Merry Christmas/midwinter solstice/Hogswatchnight,
Reinier

[1] Looking at Marco's post here:
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg27703.html
I'm actually having doubts if the 2 RTL plan is final!?!?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal