Oh my God. I think I'd prefer to write it out as a for loop. You know, so that my eyes don't bleed :-).

Err... prove it.

A compiler can unroll the loop, as well as a plethora of other tricks.

One sample output wit g++ -O2:Total time to copy 10000000 ints from one vector to other 100 times:
std::copy: 2620000
regular loop: 2870000
</code>Without optimizations:

Total time to copy 10000000 ints from one vector to other 100 times:
std::copy:    2830000
regular loop: 30390000

Satisfied?

Using cout would have been pointless as its overhead would have been way too high for measuring the actual looping process

[edit]
With vectors that fit into cache:
No optimizations:

Total time to copy 100000 ints from one vector to other 10000 times:
std::copy:    320000
regular loop: 29170000

-O2

Total time to copy 100000 ints from one vector to other 10000 times:
std::copy:    350000
regular loop: 490000

Here is the loop I had in mind:

for(int i=0;i<LOOPS;i++)
  for(it1 = intvec1.begin(), it2 = intvec3.begin(); it1 != intvec1.end(); it1++, it2++)
    (*it2) = (*it1);

With regular loop changed to that, and -O2:

Negligible 1.5% difference.

Anyway, I was just playing - if there is a good way to use <algorithm> by all means, you should use it.

But it's not all that important if the loop version will be more readable. This is not so in the case of std::copy, which is very straight-forward. But in the case of algorithms that require you to define a function (which will often be used only this once), it's not worth the hassle. Not unless we get lambda functions in C++.

Put all together and ran on my Core2 at 32bit:

#g++ std_copy.cpp -O3 -funroll-loops && ./a.out

Total time to copy 100000 ints from one vector to other 10000 times:
std::copy:     390000
regular loop:  550000
iterator loop: 580000
Jakub's loop:  560000

I ran it several times and there weren't much changes.

Different CPU's might give different results.

Core2Duo e4300@2.93GHz at the moment. That means 2M L2 shared between two cores and ~62% OC. Could go higher when I could somehow give it more than default voltage
Your last code with -O3 -funroll-loops gave me this:

Total time to copy 10000 ints from one list to other 100000 times:
std::copy:     1480000
iterator loop: 1520000

When I changed list to vector then iterator loop actually got faster than std::copy

Total time to copy 10000 ints from one vector to other 100000 times:
std::copy:     480000
iterator loop: 430000

Well, all I can say is when in doubt, benchmark
Also please note the speed difference between lists and vectors.

Hm, lists have faster insertions that vectors. You can remove elements in constant time. If you sort a list of MyClass (using list::sort), it could seriously outperform std::sort on vector, because it doesn't need to copy actual data, just rearrange the pointers.
However, iterating through a list is slower, because vector uses a random_iterator.

Each STL container has its strenghts and weaknesses. Sometimes it might even be more efficient to use one type for one task, and then copy the data to a different container to do something else with the data.

For example, std::set is blazing fast to get you unique, sorted data. If you needed a lot of random access on the data later, you might copy it to a vector before continuing. (Benchmark, of course.)

***

By the way, they say that the container's "native" methods could be faster than the equivalent std::algorithm (optimized for this particular container). Anybody care to benchmark operator = ?

That's a big "if". And a vector may get copied using push_back(). And if you wanted to keep the container sorted, a multiset would probably be fastest.

List can win clearly, if the copy constructor is expensive. For example when sorting std::strings.

Yes, a vector is a most general use container, because very often random access is what you need (replacement to single array). However, it is impossible to design a container that works remarkably well for all purposes, because you need a different structure for each purpose. Knowing the tools is good, also STL is designed in a way, that it is relatively easy to switch the container you are using and to move data to a different container.

I can also see how implementing your own list deters you from using std::list

For copy-expensive objects, you can sort a vector of pointers to the object. Although it is still questionable if it is worth the effort if list can do this without any extra work.
(I created an expensive class consisting of two ints and a string containing "Hello world", and overloaded comparison to sort it based on one of the randomly initialized ints. Then I sorted a vector of these objects, a vector of pointers and a list (identical data to the first vector). The results: sorting pointers ~3 x faster than first vector, sorting list ~5-6 x faster than a regular vector.)

Your idea is interesting, but wouldn't it produce massive overhead - no less than a list? Also, after sorting, wouldn't you still need to do the copying in one go (adds at least O(N) and seems tricky to do in-place)?

Anyway, I'm not saying list is better than vector per se (or the other way round). But a simple contiguous block of memory just doesn't suit well for all kinds of manipulations. Nor does any other data structure. So you have to make choices.

Finally, here's a link to compare the effectiveness of some operations with different containers. (Keeping in mind that O(N) can mean very different things with different containers.)

The rest of the site is interesting reading too!