> There's a single "I guess I would use this" container type, std::vector.
About that one... I would claim that in a majority of cases where an std::vector is used, what the author really wanted was a similar type, but whose size and capacity are fixed on construction and never change. The standard C++ library does not offer such a type - so people use vector because it's handy.
Agree with your takes on most of the containers. I also dislike how optionals are never used with containers as they were standardized later (and even then, problematically w.r.t. references). Thus, for example, if I lookup an object in a map of T's, the result should IMNSHO be an optional reference to a T.
> a similar type, but whose size and capacity are fixed on construction and never change.
There is std::array for that. Also, for a type with fixed capacity but variable (up to that capacity) size, we're getting std::inplace_vector soon™.
std::array requires the size to be set at compile-time, while I was talking about arrays whose size is determined at construction-time. Of course std::array is also quite the useful class :-)
What operations could such frozen vector offer that std::vector does not? If there are none, it doesn't need a separate data structure.
Oh, on the contrary, the separate structure is needed and useful because it offers _less_, not more:
* APIs/function signatures explain more clearly what are the intended uses of the structure that's passed.
* More potential for compiler optimization
* Some potential for having these on the stack (if the compiler deduces the size already at compile-time)
* More convenient for static analysis
* No plethora of confusing constructors (including the infernal two-element ctors which can be misinterpreted super-easily)
etc.