65

I'd like to build a std::string from a std::vector<std::string>.

I could use std::stringsteam, but imagine there is a shorter way:

std::string string_from_vector(const std::vector<std::string> &pieces) {
  std::stringstream ss;

  for(std::vector<std::string>::const_iterator itr = pieces.begin();
      itr != pieces.end();
      ++itr) {
    ss << *itr;
  }

  return ss.str();
}

How else might I do this?

Peter Wood
  • 23,859
  • 5
  • 60
  • 99
WilliamKF
  • 41,123
  • 68
  • 193
  • 295

8 Answers8

122

C++03

std::string s;
for (std::vector<std::string>::const_iterator i = v.begin(); i != v.end(); ++i)
    s += *i;
return s;

C++11 (the MSVC 2010 subset)

std::string s;
std::for_each(v.begin(), v.end(), [&](const std::string &piece){ s += piece; });
return s;

C++11

std::string s;
for (const auto &piece : v) s += piece;
return s;

Don't use std::accumulate for string concatenation, it is a classic Schlemiel the Painter's algorithm, even worse than the usual example using strcat in C. Without C++11 move semantics, it incurs two unnecessary copies of the accumulator for each element of the vector. Even with move semantics, it still incurs one unnecessary copy of the accumulator for each element.

The three examples above are O(n).

std::accumulate is O(n²) for strings.

You could make std::accumulate O(n) for strings by supplying a custom functor:

std::string s = std::accumulate(v.begin(), v.end(), std::string{},
    [](std::string &s, const std::string &piece) -> decltype(auto) { return s += piece; });

Note that s must be a reference to non-const, the lambda return type must be a reference (hence decltype(auto)), and the body must use += not +.

C++20

In the current draft of what is expected to become C++20, the definition of std::accumulate has been altered to use std::move when appending to the accumulator, so from C++20 onwards, accumulate will be O(n) for strings, and can be used as a one-liner:

std::string s = std::accumulate(v.begin(), v.end(), std::string{});
Oktalist
  • 14,336
  • 3
  • 43
  • 63
  • 3
    I like the FP way, but it's a bit weird looking at the moment. Really looking forward to c++20 to clear things up! – Mathemagician Oct 02 '19 at 18:10
  • 1
    How do you come up with the idea that calling `operator+=` would result in linear growth? Unless you reserve the capacity `string` might need to relocate the content for every single append-operation. That is the same for `+=`, `append` and `accumulate` - they all can be **O(n²)** – ABaumstumpf Sep 05 '22 at 18:38
  • 1
    @ABaumstumpf Appending a single character is amortized O(1) in all major implementations. They grow the capacity by an exponential growth factor, so that the frequency of reallocation shrinks as the string grows. So after appending many characters, the total number of characters copied due to reallocation is proportional to the number of characters appended. `accumulate` being O(n²) would be a very pathological worst case, with O(n) being the average case. Summing the sizes to call `reserve` could be an optimization or a pessimization depending on the circumstances. – Oktalist Sep 06 '22 at 18:11
  • @Oktalist "in all major implementations." But it is not guaranteed by the standard so your claimed O(n) can very well be O(n²). On the other hand with `reserve` you would guarantee it to be O(n) – ABaumstumpf Sep 09 '22 at 06:53
  • Is it confirmed C++20 std::accumulate uses std::move ? – kwaalaateimaa Jan 05 '23 at 01:27
  • @kwaalaateimaa Yes: https://timsong-cpp.github.io/cppwp/n4868/accumulate#2 – Oktalist Jan 05 '23 at 19:48
40

You could use the std::accumulate() standard function from the <numeric> header (it works because an overload of operator + is defined for strings which returns the concatenation of its two arguments):

#include <vector>
#include <string>
#include <numeric>
#include <iostream>

int main()
{
    std::vector<std::string> v{"Hello, ", " Cruel ", "World!"};
    std::string s;
    s = accumulate(begin(v), end(v), s);
    std::cout << s; // Will print "Hello, Cruel World!"
}

Alternatively, you could use a more efficient, small for cycle:

#include <vector>
#include <string>
#include <iostream>

int main()
{
    std::vector<std::string> v{"Hello, ", "Cruel ", "World!"};
    std::string result;
    for (auto const& s : v) { result += s; }
    std::cout << result; // Will print "Hello, Cruel World!"
}
Andy Prowl
  • 124,023
  • 23
  • 387
  • 451
  • 11
    Cute, but careless. It's going to allocate a new string for every single operation, because it uses `operator+` and generates a new string, instead of `operator+=` to modify an existing one. – Benjamin Lindley Mar 11 '13 at 19:45
  • 1
    I've written a library using which it would be just `s = v | sum();` that internally uses `+=` instead of `+` ;-) – Nawaz Mar 11 '13 at 19:47
  • @BenjaminLindley actually not for every since most implementations just twice capability each realloc – Galimov Albert Mar 11 '13 at 19:49
  • +1 for using free begin() end() instead of .begin .end member functions. – srking Mar 11 '13 at 19:50
  • @PSIAlt: Huh? Is that sentence missing some words? Because I don't understand it. – Benjamin Lindley Mar 11 '13 at 19:52
  • 1
    @PSIAlt: Read it again, it allocates a new string for every operation because every operations _generates a new string_. The doubling-size-optimization doesn't affect this. BenjaminLindley: he's talking about how string "doubles" it's capacity when you put too much in it. – Mooing Duck Mar 11 '13 at 19:52
  • @BenjaminLindley actually if your dataset is very big, you may first want to iterate a first time and accumulate all the string sizes, `reserve()` the target string a single time and *then* iterate again using `operator +=`. This can avoid a lot of useless reallocations. – syam Mar 11 '13 at 20:04
  • @syam but this introduces useless vector iteration – Galimov Albert Mar 11 '13 at 20:24
  • @PSIAlt which is why I mentioned that it depends on your dataset. Given enough (long) strings in the vector, the cost for iterating twice (with allows us to have a single memory allocation) will be much lower than iterating only once and reallocating the memory several times. How useless and costly do you think it is to copy the same data over and over into larger and larger buffers? ;) – syam Mar 11 '13 at 20:28
  • Using GNU C++ 2011 v5.3.1, I got an error using said example: ' In function 'int main()' error: 's' was not declared in this scope std::cout << s; // Will print "Hello, Cruel World!"' – John Greene Apr 08 '17 at 00:00
  • its **result += s + " "** if your vector doesn't have spaces between elements. – Haseeb Mir May 27 '18 at 22:43
13

My personal choice would be the range-based for loop, as in Oktalist's answer.

Boost also offers a nice solution:

#include <boost/algorithm/string/join.hpp>
#include <iostream>
#include <vector>

int main() {

    std::vector<std::string> v{"first", "second"};

    std::string joined = boost::algorithm::join(v, ", ");

    std::cout << joined << std::endl;
}

This prints:

first, second

Ali
  • 56,466
  • 29
  • 168
  • 265
8

Why not just use operator + to add them together?

std::string string_from_vector(const std::vector<std::string> &pieces) {
   return std::accumulate(pieces.begin(), pieces.end(), std::string(""));
}

std::accumulate uses std::plus under the hood by default, and adding two strings is concatenation in C++, as the operator + is overloaded for std::string.

bstamour
  • 7,746
  • 1
  • 26
  • 39
5

Google Abseil has function absl::StrJoin that does what you need.

Example from their header file. Notice that separator can be also ""

//   std::vector<std::string> v = {"foo", "bar", "baz"};
//   std::string s = absl::StrJoin(v, "-");
//   EXPECT_EQ("foo-bar-baz", s);
NoSenseEtAl
  • 28,205
  • 28
  • 128
  • 277
3

A little late to the party, but I liked the fact that we can use initializer lists:

std::string join(std::initializer_list<std::string> i)
{
  std::vector<std::string> v(i);
  std::string res;
  for (const auto &s: v) res += s;
  return res;   
}

Then you can simply invoke (Python style):

join({"Hello", "World", "1"})
Benjamin K.
  • 1,085
  • 3
  • 15
  • 24
  • 1
    Why are you taking a `std::initializer_list` instead of a `std::vector`? Also, I don't think you need to make a copy of the vector so could pass by const reference. – j b May 11 '18 at 12:19
  • @jb both initlist or vectors are wrong. what functions working with collections should take in are ranges. by application of duck typing principle, minimum requirement principle and decoupling principle. – v.oddou Dec 19 '18 at 05:15
  • @v.oddou what do you mean by "ranges" in this context? – j b Jan 07 '19 at 16:37
  • @v.oddou that looks very cool, but in the context of this answer I think it's unfair to say a `const std:vector&` is "wrong" when using `range` introduces a substantial third party dependency to solve the problem. If it is accepted into the standard library, then it becomes a different matter. – j b Jan 08 '19 at 14:59
  • @jb yes I'm thinking ahead of current standardization status. but there was an unsaid supplementary reason why I allowed myself this leap of faith, it's that you can replace "range" mentally with the next best thing we have right now and that is "two iterators". Squint your eyes to believe they are a range until it's true in c++20. Under this hypothesis it's still reasonable to say that `init_list` and `vector` are both wrong. It needs to be a template on some iterator type and take in begin and end. – v.oddou Jan 09 '19 at 02:59
  • @v.oddou that's an interesting approach I hadn't considered before. I always find myself wishing C++ had Python's iterables, the "two iterators" approach is kind of a way of achieving a similar pattern – j b Jan 09 '19 at 10:07
  • 1
    @jb yes, and this is the choice made by the library standard committee. You will find that all functions here https://en.cppreference.com/w/cpp/algorithm conform to the "two iterators" pattern. And probably will be ported to range in C++20. – v.oddou Jan 09 '19 at 10:42
  • @jb I just finished writing an article that talks about that :) If you want to take a quick glance at it https://motsd1inge.wordpress.com/2019/03/22/principle-of-maximum-opportunity/ – v.oddou Mar 22 '19 at 06:19
3

If requires no trailing spaces, use accumulate defined in <numeric> with custom join lambda.

#include <iostream>
#include <numeric>
#include <vector>

using namespace std;


int main() {
    vector<string> v;
    string s;

    v.push_back(string("fee"));
    v.push_back(string("fi"));
    v.push_back(string("foe"));
    v.push_back(string("fum"));

    s = accumulate(begin(v), end(v), string(),
                   [](string lhs, const string &rhs) { return lhs.empty() ? rhs : lhs + ' ' + rhs; }
    );
    cout << s << endl;
    return 0;
}

Output:

fee fi foe fum
user9494810
  • 33
  • 1
  • 3
1

With c++11 the stringstream way is not too scary:

#include <vector>
#include <string>
#include <algorithm>
#include <sstream>
#include <iostream>

int main()
{
    std::vector<std::string> v{"Hello, ", " Cruel ", "World!"};
   std::stringstream s;
   std::for_each(begin(v), end(v), [&s](const std::string &elem) { s << elem; } );
   std::cout << s.str();
}
Galimov Albert
  • 7,269
  • 1
  • 24
  • 50
  • 1
    Why not use `for (auto &i: v) { s << i; }` instead of the for_each line? –  Mar 14 '13 at 00:47
  • 3
    Why even use a stringstream at all? Make `s` a string, and make the lambda `{ s += elem }` – Oktalist Sep 09 '13 at 17:17
  • @Oktalist no! it's the schoolbook example of Schlemiel the painter pessimization. https://www.joelonsoftware.com/2001/12/11/back-to-basics/ – v.oddou Jan 09 '19 at 10:49
  • 2
    @v.oddou It's not a Schlemiel the painter, as `std::string` knows its own length. It doesn't have to iterate over `s` to find the null terminator. It could be improved, though, by using `std::string::reserve` to avoid repeated allocations for `s`. See also my top-voted (but not accepted) answer above. – Oktalist Jan 10 '19 at 01:30
  • @Oktalist I also upvoted your answer, it's great. But "knows its own size" doesn't appear to be guaranteed https://stackoverflow.com/a/256309/893406 – v.oddou Jan 10 '19 at 02:42
  • 1
    @Oktalist ok apparently it IS guaranteed when considering end()-begin() https://stackoverflow.com/questions/256033/is-stdstring-size-a-o1-operation/256309#comment18367004_256309 so don't mind my blabber. – v.oddou Jan 10 '19 at 02:48