
On Wed, Aug 25, 2010 at 1:42 AM, joel falcou <joel.falcou@lri.fr> 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