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 :-) _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
