Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-23 21:25:06

On Sat, Jan 22, 2011 at 5:38 AM, Nevin Liber <nevin_at_[hidden]> wrote:
> On 21 January 2011 11:56, Dean Michael Berris <mikhailberis_at_[hidden]>wrote:
>
>> No changing arbitrary content in the string. Concatenation is a
>> process of creating new strings.
>>
>> Ultimately the underlying string should be efficient
>
>
> Please describe how you are going to make this efficient, if concatenation
> effectively requires an allocation (once past the small string optimization)
> and a copy.
>
> It is one thing to be in a garbage collected world where the cost of
> allocation is relatively cheap, but that world is not C++.

Correct.

So this implementation pre-supposes that there is an efficient "arena"
allocator, not dissimilar from Boost.Pool, or even one that allows
"growing" of buffers (via a call similar to realloc), or even
something akin to what Interprocess has in the form of a
`managed_heap_memory`. You can then implement an optimization for
concatenation if you knew that a string to be concatenated is only
referred to by only one referrer/proxy, that the RHS is a temporary,
and that the resulting string would only be assigned.

This implies that you need to have some smarts in the implementation
-- potentially having an EDSL just for string
concatenation/operations. It's needless to say that Proto would be
good to use in this EDSL so that you had the capability of knowing
whether strings are temporaries (generated in-place from literal
strings) or an lvalue.

HTH

-- 
Dean Michael Berris
about.me/deanberris