[fpc-devel] Re: enumerators

[Marco van de Voort]

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.

> Traditional For loops have their use with array structures, iterators have
> their use with other data structures.

Yes. But this fits neither. Array of encoding granularity remains used, and
for fundamental, speed sensitive routines there are the inline procedures.

I don't see the need to create another first class type to iterate a first
class type.
 
> >> 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?

(and even if it succeeds it would be very, very slow, since strings are not 
infinite in length, the constants still matter)

> All that could be encapsulated in a class, with flexible internal string
> representation.

I don't see why a string should be a class. In FPC it is already a first
class type.

> > This is dog slow. You can make such library for special purposes, but for
> > most day to day use this is overkill.
> 
> I don't think so, and you don't either:
> 
> > The most common stringoperations that the avg programmer does is searching for
> > substrings and then split on them, something that can be perfectly done in
> > UTF-8.
> 
> :-)

True, but I'm not an avg programmer :-)