[fpc-devel] Re: enumerators

[Hans-Peter Diettrich]

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