Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-26 13:11:37

On Thu, Jan 27, 2011 at 2:02 AM, Stewart, Robert <Robert.Stewart_at_[hidden]> 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