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
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'.
-- 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