Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-26 22:54:51

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