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?
That uses widestrings to support non-ASCII characters for ODBC and
should be in the fcl-db.
I suppose chosing any string type that is convenient in various fcl
units could lead to a lot of useless conversions.
How will this be avoided?
That remains to be seen.
I suspect that we'll add a .AsAnsiString version to TField, in addition to
.AsWideString, and add a field type: ftAnsiString.
The low-level dataset driver will have to decide what to do with data coming in:
- AnsiString
- WideString
The .AsString will then pick the one that corresponds to the type of RTL.
ftString will be an alias to ftAnsiString or ftWideString, depending on the RTL.
This is different from what Delphi does, which simply says that
.AsString is now equal to .asWideString.
This way, you can decide what to do if you have a Unicode RTL:
Use .AsString and go with the conversions in case of unicode RTL.
Use .AsAnsiString and use ansistring if you know the database has ansi data.
Use .AsWideString.
But that remains still all to be decided.
Like I said: Trunk will most likely become rather unstable once we get started
:-)
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
