[einpoklum]

> 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]

> 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]

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 :-)

[SJC_Hacker]

You can construct the vector with a given size. As long as you don’t push_back, beyond capacity, these should be o dynamic allocations.

If you want to get f cy you can also give it a custam allocator and throw an exception if you do this by mistake

[einpoklum]

> As long as you don’t push_back

But that's the point. You _can_ push_back, or resize, or reserve, etc. etc. My claim is that the more common use case is the one where this _cannot_ happen.

> If you want to get f cy you can also give it a custam allocator

And then nobody will want to use it, because that's not interchangeable with containers vector with the default allocator, and also difficult to understand. I mean, look at PMR allocators, which are not even that custom. They see very little use I'm afraid.

[Joker_vD]

Well, if you want to, I can write you a forwarder-wrapper around a std::vector that would inhibit allocation-inducing operations. Now, getting it into stdlib, that's a different matter entirely...

Also, do I understand correctly that you want both the capacity and the size fixed, i.e., the container's elements have to be pre-constructed and supplied to the constructor via an initializer list?

[afdbcreid]

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]

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.

[nemetroid]

How are any of these achieved by a vector-like type with capacity frozen at construction time?

[quuxplusone]

The reason I'd want "frozen-size vector" is to replace pairs of data members of the form `T* foos; size_t foos_len;` without paying another 8 bytes to store a useless capacity that's never going to change.

But I don't think that makes such a container worth adding to the STL. So far, it hasn't even been worth writing in our own code. But that's the reason I've thought about writing it.

[uecker]

This is how I designed my vector in C. Note it is still not frozen as you can use realloc just fine (even with good performance) and/or external tracking of the capacity in tight loops.

https://uecker.codeberg.page/2025-07-20.html

I probably will still add a version with capacity, because people may insist on it, but personally I like the one without much more so far.