[fpc-devel] Re: enumerators

Hans-Peter Diettrich DrDiettrich1 at aol.com
Wed Nov 17 01:27:20 CET 2010

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 

>>>> 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.


More information about the fpc-devel mailing list