Re: [boost] [Potentially OT] String Concatenation Operator

Subject: Re: [boost] [Potentially OT] String Concatenation Operator
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-08-24 22:20:56

On Wed, Aug 25, 2010 at 1:42 AM, joel falcou <joel.falcou_at_[hidden]> wrote:
> Can't you just work over the wstring example in proto and use this as a base
> for a intelligent string concatenation system ?

I can... and I just might... but not now. :)

I'll read through that particular example, thanks for the pointer.

> basically, any termianl containing a string of any kind and operator+ or w/e
> build a proto tree that you affect to your string.
> This expression is crawled down at RT to gatehr the length, allcoate the
> buffer and do another traversal for copying each part
> where it does. Then use proto::lit() to build char[], char* or std::string
> into the proto AST.

I wonder though, when you say RT you mean "Run-Time"? Is there a way
to do it possibly at compile time, gathering the length of literal
strings at least?

My biggest problem with the run-time approach is that it doesn't allow
me to be smart about the lengths at compile time. A different string
type then that has lazy construction semantics might be memory-heavy
if left to be constructed at runtime alone. I'm wondering whether
there's a way to create a string type that (like the Spirit rule
template) encapsulates the building blocks required to build the
string at some point in time later (at evaluation time) and doesn't do
anything until the whole string is actually required. Then that type
can expose iterators that can be treated as a range, which builds the
string one character at a time.

Disregarding the requirement for constant-time random access for
example, a string type that builds the string on demand might make
part of its building blocks a generator tied to an external source. In
case constant-time random access would be required, then the string
can lazily build a contiguous string out of the building blocks, cache
it, and then offer a read-only random access iterator over that (or
even use it on an operator[] overload).

I still have not anything concrete in mind and was just wondering
aloud and thinking that something like this might have already been
done by someone else. Might be interesting to work on at some point I
think. ;)

-- 
Dean Michael Berris
deanberris.com