It is faster , but less space efficient .

The thing is - you cannot determine even an approximate size of the resulting vector beforehand .

Sure , the input {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16} requires the output vector to have a size equal to 16 elements .

And input {1,1,2,2,3,3,4,4,5,5,6,6,7,7,8,8} requires the output vector to have a size equal to 8 elements .

While input {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1} requires the output vector to have a size equal to just only 1 element .

Favoring speed over space is generally a good idea , but i think it is also worth knowing when "reserve" can be used with/without drawbacks .

This code is good short and straight to the point. My only question is what does the #include algorithm> #include iterator> and #include unordered_set> do for this code?

Goot solution but why we need #include <unordered_set> here?

You could also call the member function "reserve" on the result vector before doing the unique_copy algorithm. This would mean one heap allocation instead of an unknown number of allocations as the vector grows in size.

Maybe that's the point, make you aware of such tools

Why is there always a standard library function that does exactly what the task says to do?