Appending a Vector to a Vector

Best way to append vector to vector

In my opinion, your first solution is the best way to go.

vector<>::insert is designed to add element so it's the most adequate solution.

You could call reserve on the destination vector to reserve some space, but unless you add a lot of vector together, it's likely that it wont provide much benefits: vector<>::insert know how many elements will be added, you will avoid only one reserve call.

Note: If those were vector of more complex type (ie a custom class, or even std::string), then using std::move could provide you with a nice performance boost, because it would avoid the copy-constructor. For a vector of int however, it won't give you any benefits.

Note 2: It's worth mentioning that using std::move will cause your source vector's content to be unusable.

How to append a vector to a vector r - in a vectorized style

You could just use normal vector indexing within the loop to accomplish this:

vector <- numeric(length=100)
for (i in 1:10) {
  vector[(10*i-9):(10*i)] <- 1:10
}
all.equal(vector, rep(1:10, 10))
# [1] TRUE

Of course if you were just trying to repeat a vector a certain number of times rep(vec, 10) would be the preferred solution.

C++ append vector into another vector

v1.insert(v1.end(), v2.begin(), v2.end());

Nice way to append a vector to itself

Wow. So many answers that are close, none with all the right pieces. You need both resize (or reserve) and copy_n, along with remembering the original size.

auto old_count = xx.size();
xx.resize(2 * old_count);
std::copy_n(xx.begin(), old_count, xx.begin() + old_count);

or

auto old_count = xx.size();
xx.reserve(2 * old_count);
std::copy_n(xx.begin(), old_count, std::back_inserter(xx));

When using reserve, copy_n is required because the end() iterator points one element past the end... which means it also is not "before the insertion point" of the first insertion, and becomes invalid.

---

23.3.6.5 [vector.modifiers] promises that for insert and push_back:

Remarks: Causes reallocation if the new size is greater than the old capacity. If no reallocation happens, all the iterators and references before the insertion point remain valid. If an exception is thrown other than by the copy constructor, move constructor, assignment operator, or move assignment operator of T or by any InputIterator operation there are no effects. If an exception is thrown by the move constructor of a non-CopyInsertable T, the effects are unspecified.

append a rvalue vector to a vector in O(1) time

Why would being an rvalue matter at all to this? Big-O notation counts the number of operations done in a process. Whether those operations are copy or move, if the number of operations performed is directly proportional to the number of items in the source list, then it is an O(n) process.

And if you're going to copy/move a contiguous sequence of elements into another contiguous sequence of elements, with the result being contiguous, that process must be be O(n) (at least), where n is the number of elements in the source sequence. Even if it did a memcpy of the source elements, memcpy of some sequence of Ts is O(n) on the number of Ts in the sequence.

Appending array into vector

Forget that int[3] names a type. C arrays don't behave like sensible values. Arrays are named std::array<type, count>.

#include <vector>
#include <array>

int main()
{
  std::vector<std::array<int, 3>> matchVector;

  std::array<int, 3> msmTemp;

  msmTemp[0] = 1;
  msmTemp[1] = 2;
  msmTemp[2] = 3;
  matchVector.push_back(msmTemp);
  msmTemp[0] = 4;
  msmTemp[1] = 7;
  msmTemp[2] = 0;
  matchVector.push_back(msmTemp);

  for(auto & arr : matchVector)
  {
    for(auto i : arr)
    {
      std::cout << i <<", ";
    }
    std::cout<<"\n";
  }

  return 0;
}

Appending to vector of union

There is no clean way to do this for the simple reason that given an arbitrary instance of this union there is no authoritative way for a generic, template-based function/method, like std::vector::push_back to know which member of the union is active, in order to execute the member-specific copy/move operation, when at least one member of the union is not a POD. There's nothing inherent to any particular instance of a union that states "this specific union contains a std::string so to copy/move it you will use std::string's appropriate copy/move operator". C++ simply does not work this way, this is fundamental to C++. There is no workaround, and no syntax for this.

In general, due to C++'s foundation in type-safety, an inhererently type-unsafe union, when used together with non-POD members like std::string, produces an end result with quite limited capabilities.

The least amount of pain for you would be to replace your union with C++17's std::variant, a type-safe union. push_back then becomes a big, fat, nothing-burger.

---

Related Topics