Michael Schnell schrieb:
On 10/11/2011 11:20 AM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
Because it expects and UTF8 argument, and provides an UTF8 result, so
that no further conversions are required when used with strings of
exactly that encoding.
I don't understand your argument. If ToLower gets a new string that is
UTF8 encoded, the result should be a new string that is UTF8 encoded. So
why bother. Checking the encoding Word and branching tho the appropriate
encoding-aware functionality is a very fast operation.
Why implement the upper/lower translation N times, when afterwards the N
encodings have to be converted into the Result encoding? Where the
encoding conversions already exist...
With dynamically encoded Strings "ToLower" should work for any encoding.
You mean something like this?
function ToLower(s: RawByteString): RawByteString;
[dunno whether RawByteString is an allowed Result type at all]
In fact I still don't understand the difference between a type called
"RawByteString"and a basic new String that happens to be set to the
encoding "RawByte".
I only have the Delphi implementation at hand, and there every string
type has an associated encoding. E.g. the default AnsiString has
codepage 1252 encoding, and when a string is assigned to such a
variable, it is converted into codepage 1252. The *only* exception is
the RawByteString type, which can have any encoding.
IMO, calling ToLower with a string that is set to the encoding "RawByte"
does not make sense and should generate an exception.
When a string is assigned to an RawByteString, both point to the
original string, which has a valid (non-raw) encoding. The only
exception is an empty string, with a Nil pointer and consequently no
stored encoding - but such a string never deserves any conversion.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
