Good day everyone, I am currently taking some time to implement some functionality into cpp-netlib [0] (shameless plug) and somehow I've stumbled into a sort of conundrum. First, some background: I'm trying to abstract away the string building routines of the network library to come up with the most efficient way of doing the following: 1. Efficiently allocate space to contain a string being built from literals and variable length strings. 2. Be able to build/traverse the string lazily (i.e., it doesn't matter that the string is contiguous in memory as in the case of C-strings, or whether they are built/backed by a stream as in Haskell ByteString). 3. As much as possible be "automagically" network-safe (i.e. can be dealt with by Boost.Asio without having to do much acrobatics with it). At the heart of the issue is the semantics of the '+' operator to signify string concatenation. Trying not to sound pedantic about it, the addition operator in traditional mathematical notions is both commutative and associative, while string concatenation is not commutative but right associative. Trying to remember my C++ operator precedence and associativity rules, it looks like operator% and/or operator^ might be good candidates for this, but only in expression templates where you fold from the right. Now I don't want to start beating on the STL's standard string implementation, but I'd like to know if anyone is already working on a string implementation that meets the above requirements? I'd be happy to wait on compile times with Proto, if it means I can save big at runtime. What I wanted to be able to do (and am reproducing at the moment) is a means of doing the following: string_handle f = /* some means of building a string */; string_handle s = str("Literal:") ^ f ^ str("\r\n\r\n"); std::string some_string = string_handle; // convert to string and build lazily If for instance f were also a literal, then s can efficiently already hold the string in some fixed sized byte array whose size is determined at compile time. Somehow the function str() would only be able to take a literal and look something like this: template <size_t N> inline bounded_fragment<N> str(char const s[N]) { return bounded_fragment<N>(s); } The evaluation of the assignment (or copy constructor) of the string_handle will then evaluate the expression template and already know at compile time: A. Whether the string is just a long literal and allocate enough space to effectively hold the whole string at compile time, or at least reserve enough space statically (a boost::array perhaps) so that a simple range copy can be done (and optimized by the compiler as well) B. Whether the string is a list of variable length strings, having a list of handles built C. Whether it is a mix and have all the adjacent literals joined effectively at compile time and those variable sized strings retrieved when required Pointers to ongoing work would be most appreciated -- I'm currently too preoccupied to chase this particular rabbit down the hole (I'm chasing a different rabbit in a different hole) but maybe this is an interesting enough problem for the template metaprogramming guru's to look into? Thanks in advance and I look forward to any thoughts/pointers. -- Dean Michael Berris deanberris.com