On Thu, Jan 27, 2011 at 2:02 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Dean Michael Berris wrote:
If what you substitute for String is the hypothetical `boost::string` then what happens is the view will interpret it as raw data underlying the view.
If you're substituting a view<some_encoding> for String then what happens is the internal view<encoding> construction will hold a copy of the (immutable) view<some_encoding>, and upon access to the iterators would do the transcoding on the fly.
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. 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. :) -- Dean Michael Berris about.me/deanberris