Re: [boost] another draft of the string algorithms

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-26 21:35:09

On Thursday 26 July 2001 06:52, you wrote:
> Darin Adler wrote:
> >      vector<string> split(string [, delimiter characters]);
>
> Returning a vector is IMHO both unnecessarily constraining and
> unnecessarily inefficient. The equivalent function in my own library
> looks like this:
>
>     template <typename OutputIterator> OutputIterator
>         split(const std::string& source, OutputIterator target,
>             const std::string& delimiters = " /f/n/r/t")
>
> The string fragments are written into the sequence starting with target
> (which will normally be an inserter); the return value is past the end
> of the output sequence (i.e. target advanced by the number of
> fragments).
>
> Typical usage:
>
>     std::string seq("foo bar zap");
>     std::vector<std::string> pieces;
>     split(seq, std::back_inserter(pieces));

Two comments on this:
        - Efficiency isn't always the most important design guideline. I'd be in 
favor of having both forms, because the current version is so darn easy to 
use. There's always the possibility of lazy evaluation as well: return an 
object that is implicitly convertable to std::vector<string>, 
std::list<string>, etc.
        - It isn't necessarily inefficient to have:
std::vector<string> strings = split(source);
          , because the compiler doesn't necessarily have to call any copy 
          constructors (I know GCC performs this optimization).

> >      string join(vector<string> [, string separator]);
> >      string join(start iterator, end iterator [, string separator]);
>
> Why do you need the first when you have the second? This is the
> range-vs-container debate all over again, isn't it? :-)

I'm not touching this :)

        Doug