[shrughes]

That blog post doesn't address the worst-case running time argument, and doesn't measure worst-case running time costs, since it measures batches of 5000 operations at a time. And hey, it's about a workload that totally obviates worst-case running time considerations by requiring a linear scan for every operation.

If you responded by pointing out that even when the vector consumes half of physical memory, the worst case running time isn't going to be any worse than iterating through all of physical memory, which isn't really so bad, and that for the vast majority of vectors it's going to cost less than a page fault, maybe take a couple of microseconds, to copy those values, you might have an argument that actually addressed spinlocked's point.

Of course, std::vectors are only good for copyable types, and copyable types are the devil.

[marshray]

If you don't mind me asking ... what religion are you that considers copyable types to be the devil?

[shrughes]

Presbyterian. Well no, but see http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... for some rationale in that direction. Generally speaking you might note that in Java and C#, if you want to copy a data structure, you have to do so explicitly.

[marshray]

Yeah I agree that one should intentionally enable or disable copy and assignment for a type. It might even make sense to disable implicit copying and make an explicit method for it instead.

The C++11 move constructor and move assignment operator seem to me to be a wonderful middle ground.