In our previous episode, Hans-Peter Diettrich said: > > > > 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.
Only the ones where surrogates really matter. > >>> 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. This sounds awfully like the argument long ago that ansistrings wouldn't eventually be slower than strings, since the optimizer would optimize nested inc/decref calls away, so that there would be no more than one call per string per procedure. Afaik, I'm still waiting (and realize now that it is a lot harder since the refcount has to match pretty closely due to e.g. the possibility of exceptions) Yes, you can throw it all on future optimization, but I more a one bird in the hand kind of guy. > The result were a general Unicode string class, not bound to a specific > encoding, similar to the Delphi Unicode string representation. I see no implementation details here at all that supports such statement. I see a wish, not a plan. The devil is always in the details. > > 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, ... of chars. > that can contain data of any kind - every data type or structure can be > seen as a collection of bytes or chars. I don't see the any kind stuff. Yes, every type that has a variable memory footprint can store everything in theory, but that is as far as it goes. > 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. 1. I don't see zip or graphics encodings 2. Since there are some variable requirements on the type, I don't see a good reason to scale that up to "all" > 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. You totally lost me here. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
