[fpc-devel] Re: enumerators
Marco van de Voort
marcov at stack.nl
Tue Nov 16 20:40:37 CET 2010
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
> 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
> >> 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
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
I don't see why a string should be a class. In FPC it is already a first
> > 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 :-)
More information about the fpc-devel