Subject: Re: [boost] [Potentially OT] String Concatenation Operator
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2010-08-25 05:38:37
On 24/08/2010 17:11, Dean Michael Berris wrote:
> 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).
It seems to be what you're looking for is a range (or a slight
refinement). I.e. an entity that can be iterated.
Arrays, tuples, strings, vectors, lists, a pair of istream_iterator, a
pair of pointers, a concatenation of ranges, a transformed range, etc.
are all ranges.
> 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).
I suppose you'd have to linearize it.
Sending it in multiple chunks would have different behaviour on
different types of sockets.
> 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
How about:
boost::lazy_range<char> f = /* some means of building a string */
boost::lazy_range<char> s = boost::adaptors::join(
boost::as_literal("Literal"),
f,
boost::as_literal("\r\n\r\n")
);
std::string some_string;
boost::copy(s, std::back_inserter(some_string));
boost::lazy_range is not actually in boost, but that would be a type
erased range, and I've got an implementation somewhere.
Of course, not using type erasure at all (i.e. replacing lazy_range by
auto or the actual type of the expression) would allow it to be quite
faster.