On Sat, 22 Dec 2012, dev.d...@gmail.com wrote:
Hi,
thanks for the quick reply.
So the direction seems to be quite clear...
... unfortunately this seemingly wasn't communicated clearly enough to the
surroundings.
Because of the requirement for backwards compatibility with FPC itself,
we'll make 2 RTLs: one backwards compatible, one with the new unicode string.
Do you mean really seperated sources or a comiler switch?
A bit of both :-)
What's the problem to use the "new" RTL with Ansistring? I can't see a
problem, if it doesn't use direct string access...
For obvious reasons, the RTL uses direct string memory access in many places.
... of course you have to compile it accordingly..
You can use ansistring, no problem.
The problem are classes. If I define
TComponent = Class(TPersistent)
Published
Property Name : String;
end;
Then name will be of the string type as declared in the unit where TComponent is defined.
For properties this is not so much of a problem but if you try to override something like
Procedure(Arg : String); virtual;
Then the string type must match the original string type as in the original declaration,
no matter what the string type in your particular unit.
so you can choose which string type you need per unit
Can a project wide choice override this for *any* unit (3rd party) or will
there be conversion going on between the different units?
There will always be conversion if
1) a unit specifies a string type by itself.
2) the unit comes in compiled form.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
