Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk