Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-01-26 13:27:30

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? ;-)

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

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.