Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2011-01-27 08:18:48

On Thu, Jan 27, 2011 at 14:41, Dean Michael Berris
<mikhailberis_at_[hidden]>wrote:

> On Thu, Jan 27, 2011 at 8:09 PM, Yakov Galka <ybungalobill_at_[hidden]>
> wrote:
> > On Thu, Jan 27, 2011 at 12:57, Dean Michael Berris
> > <mikhailberis_at_[hidden]>wrote:
> >
> >> So more to the point, the real thing I want to focus on is the
> >> immutable string. :)
> >>
> >
> > So isn't SGI's rope (without all the mutable interface) a good immutable
> > string?
> >
>
> I think so... but there are some things that I think would be good to
> have in a string implementation that is by design immutable. There are
> certain things like:
>
> * Interning -- similar to what the flyweight implementation does but
> centers on strings and substrings
>

Not sure what you mean here...

* Reference counting -- as already pointed out by others earlier on
>

ropes are implemented through reference counting.

* Lazy transformations -- which I'm not sure would fit entirely in the
> way SGI's rope is described
>
* Simple DSEL for concatenation and layering transformations -- this
> would be good for efficiency reasons and would generally influence the
> internals of the implementation
>

I don't understand why people introduced the ^ syntax here. Plain old
operator + and += looks fine for me.
Probably transformations should not be part of the string interface. I don't
know what transformation you are talking about, but consider transcoding or
unicode case conversion. Both can't be done (in general) by starting at
arbitrary place in the string, so you arrive at a design in which
transformations are forward iterator ranges.

Btw, can someone answer this question (
http://stackoverflow.com/questions/3894358/what-is-the-concatenation-complexity-of-balanced-ropes)
?

-- 
Yakov