On 06/27/2013 12:26 PM, Marco van de Voort wrote:
That already has been decided, everything Delphi compatible.
I was just speaking hypothetic case.
The starting point of the discussion was the possibility to improve the
compiler/library and potentially introduce mode settings that introduce
a different (better) behavior. I don't suppose there is any
documentation on fpc yet that exactly describes the behavior when
assigning a RawByteString to a normal String (in DXE I did not see such
documentation either)
In general, it has been proven time and time again that deviating from
Delphi is nearly always the worse choice.
Here the deviation is just doing a decent implementation for a case that
is depreciated and not decently defined in the Delphi docs, and for
which a decent behavior can easily be defined and implemented.
I don't think quirks mode would be useful. It is not just syntax,
Yes, it is "just syntax" as what I suggest to implement in DXE just is a
depreciated statement (e.g. myString := myRawByteString).
In general the average code doesn't really honour such fine
differences, so in practice this doesn't matter.
This is very wrong IMHO.
It offers the possibility to create functions that can be fed with any
(normal) type of String and act on this without doing a conversion.
A prominent example is TStringList. I have no idea how it is implemented
in DXE, but using "decent" RawByteStrings it can be implemented in a way
that can be used with all strings without a severe performance hit.
Another example is the Lazarus LCL that could provide a user interface
done with RawByteStrings and thus allow for the user to use any encoding
that is optimum for his application and LCL internally can use the
string type that best matches the underling OS. The conversion - if
necessary - would automatically be done at a decent point in the work.
The performance hit would be minimal as the compiler only needs to
implement any additional code (over using the same string type
everywhere) when a normal String and a RawByteString get together in a
single statement. Regarding that LCL calls are not done in close loops
this would be close to zero.
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
