n00bish std::vector question

This is much simpler than you're making it sound. :-)

m_Sets.push_back(MyThing()); // Construct a temporary, calling the default constructor

Incidentally, to append a bunch of new objects to the vector, you could do m_Sets.resize(m_Sets.size() + n); (this will call the default constructor for each new object; std::vector::resize is overloaded so that you can specify what you want done for each new element: m_Sets.resize(m_Sets.size(), MyThing(foo, bar)); would call the constructor with foo and bar as parameters).

Well okay, I tried that (actually I was also having trouble with resize), because I hid the copy constructors (as I don't want this item to be copyable) - but then I realised that the vector needs the class to have at least the default copy constructor in order to work. Presumably things like resize () need it.

Things were so much simpler in .NET land ;).

It needs the copy constructor because the vector will resize (when its size exceeds its capacity) by allocating a new internal array (usually of some multiple of the previous size rather than simply a constant size larger, to avoid reallocating more often than necessary) and copying the existing elements into this array.

I think objects stored in a container must be copy constructable (ible? able?) and assignable (although you needn't necessarily provide these – the default ones may do).

It doesn't work that way.

std::vector always copies things into its own storage. It can't just create instances of the element type, because there's no way to tell it how to call the element type's constructor (consider for example that it doesn't know how many arguments the constructor has). With a *copy* constructor, it knows, because there is simply one argument of the same type. But in any case, it certainly does "allocate" all those instances no matter what.

You must be able to copy-construct your object properly in order to store it in a std::vector. Actually, this holds for other standard library containers, too. In fact, it's just plain a darn good idea. It doesn't make sense to try to do that kind of complicated "management" stuff if you can't even copy the darn thing. Non-copyable objects (such as streams) are basically meant for dealing with one-on-one, maybe passing them by reference (obviously not by value!) between functions.

What are you really trying to do? And why?