Hacker News new | past | comments | ask | show | jobs | submit
einpoklum | on: C++: The Documentary
> 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.

Joker_vD | parent | next
> 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™.

einpoklum | root | parent
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 :-)
afdbcreid | parent
What operations could such frozen vector offer that std::vector does not? If there are none, it doesn't need a separate data structure.
einpoklum | root | parent
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.