[fpc-devel] Re: enumerators
Marco van de Voort
marcov at stack.nl
Wed Nov 17 10:12:58 CET 2010
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
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
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.
More information about the fpc-devel