Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
Yes, but the realisation should be that the holding on array indexing is
what makes it expensive. The problem could be strongly reduced by removing
such array indexing skeleton from all routines where it is not necessary.
Why fall from one extreme into the other one?
I don't consider it an extreme, on the contrary. Trying to fix this is
extreme IMHO.
Sorry, I understood that you want to replace all for loops by iterated
loops.
UTF encodings have their primary use in data storage and exchange with
external API's.
And in memory.
That's the design flaw, IMO. When UTF-8 strings are re-encoded before
processing,
How, when? How do you avoid repeated encoding/decoding/encoding cycles?
The encoding is only changed on demand. Once converted into a
computational format (e.g. UCS2), the internal representation deserves
no more changes. Another conversion may occur when a copy in a different
encoding is requested; since a copy operation already is O(n), a
conversion will not increase that order.
The result were a general Unicode string class, not bound to a specific
encoding, similar to the Delphi Unicode string representation.
I don't see why a string should be a class. In FPC it is already a first
class type.
Name it as you like, but a first class string type is only a container,
that can contain data of any kind - every data type or structure can be
seen as a collection of bytes or chars.
Take Unicode, zip or graphics encodings as examples for data types, that
can be stored in such a container, and you'll see that every different
encoding deserves different support functions - the data type becomes
polymorphic. Having reached that point I see a need for a base class,
that reflects the *nature* of the information, from which classes for
specific encodings can be derived. A user will be happy with the
abstract type (see TStrings), and must not bother with specific
encodings, that can result in bad behaviour when not choosen properly.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
