Std::copy and std::vector problem?

This is undefined behavior reserve() allocates a buffer for at least one element and the element is left uninitialized So either the buffer is big enough and so you technically can access elements beyond the first one or it is not big enough and you just happen to not observe any problems The bottom line is - don't do it. Only access elements that are legally stored in the vector instance.

This is undefined behavior - reserve() allocates a buffer for at least one element and the element is left uninitialized. So either the buffer is big enough and so you technically can access elements beyond the first one or it is not big enough and you just happen to not observe any problems. The bottom line is - don't do it.

Only access elements that are legally stored in the vector instance.

I would also prefer calling resize() over reserve() before copying elements in - otherwise you can't iterate the elements and size() will still return 0, plus the next push_back() will start overwriting what you copied. – AshleysBrain Nov 10 '10 at 13:23 I got it. I should resize() instead of reserve().

What is the difference between the two? – nakiya Nov 10 '10 at 13:36 @nakiya: The key you have to kindly ask vector to allocate a big enough buffer, otherwise it is UB. – sharptooth Nov 10 '10 at 13:42 "that's how many elements you can legally access" - no, you can't legally access them if all you've done is reserve.In the case of a vector perhaps it's hard to see why, but if the vector was of a class type then they would not have been constructed if all you did was reserve, and even assignment therefore might not work.

The standard forbids it regardless of the type, though. An implementation is allowed to allocate the memory, but still not return a pointer/iterator to it from begin(). – Steve Jessop Nov 10 '10 at 13:56 @Steve Jessop: Confusing to say the least.

:) EDIT: got it. – nakiya Nov 10 '10 at 14:04.

This is wrong! It is undefined behavior to access memory you don't own, even if it works in an example. The reason, I think, is that std::vector would reserve more than one element.

Both are wrong as you are copying to empty vector and copy requires that you have space for insertion. It does not resize container by itself. What you probably need here is back_insert_iterator and back_inserter: copy(p, p+5, back_inserter(v)).

Because the stars aligned. Or you were running in debug and the compiler did something to "help" you. Bottom line is you're doing the wrong thing, and crossed over in to the dark and nondeterministic world of Undefined Behavior.

You reserve one spot in the vector and then try to cram 5 elements in to the reserve-ed space. Bad. You have 3 options.

In my personal order of preference: 1) Use a back_insert_iterator which is designed for just this purpose. It is provided by #include . The syntax is a bit funky, but fortunately a nice sugar-coated shortcut, back_inserter is also provided: #include // ... copy( p, p+5, back_inserter(v) ); 2) assign the elements to the vector.

I prefer this method slightly less simply because assign is a member of vector, and that strikes me as slightly less generic than using somethign from algorithm. V. Assign(p, p+5); 3) reserve the right number of elements, then copy them.

I consider this to be a last ditch effort in case everything else fails for whatever reason. It relies on the fact that a vector's storage is contiguous so it's not generic, and it just feels like a back-door method of getting the data in to the vector.

Because you were unlucky. Accessing memory not allocated is UB.

Most likely because an empty vector doesn't have any memory allocated at all, so you are trying to write to a NULL pointer which normally leads to an instant crash. In the second case it has at least some memory allocated, and you are most likely overwriting the end of an array which may or may not lead to a crash in C++. Both are wrong.

It would be wrong, by the way, even to copy 1 element to the vector that way (or to reserve 5 then copy that way). The reason it most likely does not segfault is that the implementor felt it would be inefficient to allocate the memory for just 1 element just in case you wanted to grow it later, so maybe they allocated enough for 16 or 32 elements. Doing reserve(5) first then writing into 5 elements directly would probably not be Undefined Behaviour but would be incorrect because vector will not have a logical size of 5 yet and the copy would almost be "wasted" as vector will claim to still have the size of 0.

What would be valid behaviour is reserve(5), insert an element, store its iterator somewhere, insert 4 more elements and look at the contents of the first iterator. Reserve() guarantees that the iterators do not become invalidated until the vector exceeds that size or a call such as erase(), clear(), resize() or another reserve() is made.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.