On Thu, Jan 27, 2011 at 2:27 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Dean Michael Berris wrote:
On Thu, Jan 27, 2011 at 2:02 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Doesn't your approach mean that the work done to produce the code points or characters (or transcoding) is not cached? Each iteration of the view does the work again. That can be appropriate in many cases, but there are also plenty of cases in which one wants to do the decoding/transcoding and save the result for repeated use.
I think I remember saying something about "smarter" iterators at some point earlier. ;) Also notice that an instance of the view<...> can have additional information that's unique to the encoding.
Isn't that a little like the cartoon of the complicated math covering a chalkboard with "and then a miracle happens" in the corner? ;-)
Hah! LOL :D Yeah I realize that. However, short of showing you the code of how it would be done, I'd prefer the "and then a miracle happens" preview at this stage. :)
It's entirely possible to implement the caching at the view layer (and even at the iterators) that can even be shared across instances of the view much like how an immutable string would do it. Immutability brings a lot of good things to the table that would otherwise not be "safe" to do with a mutable string data structure. :)
Perhaps it's also reasonable to think of types that hold characters or code points as being constructed from an appropriate view of the immutable string. Those types can then cache the decoded/transcoded result of iterating a view. Those might be the higher level, encoding-aware string types that others are looking for.
Yes, but really I think the view<encoding> is the encoding-aware string type mostly because if you convert it to an std::string for example or into a buffer and look at it like a `char const *` or even `wchar_t const *` then you basically get what you'd need for the C or OS APIs. I just prefer calling a spade a spade and not say `string` when I really mean a `view<encoding>` -- because largely I think everyone would agree that the string data structure really doesn't have an intrinsic property that relates to an 'encoding'. HTH -- Dean Michael Berris about.me/deanberris