3 ms·

> 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

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

afdbcreid 5mo ago
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 5mo ago
  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 5mo ago
    How are any of these achieved by a vector-like type with capacity frozen at construction time?
- quuxplusone 5mo ago
  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 5mo ago
    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 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.
Joker_vD 5mo ago
> 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 5mo ago
  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 5mo ago
    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 5mo ago
      > 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 5mo ago
        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 5mo ago

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 5mo ago
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 5mo ago
  How are any of these achieved by a vector-like type with capacity frozen at construction time?
quuxplusone 5mo ago
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 5mo ago
  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 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.

Joker_vD 5mo ago

> 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 5mo ago
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 5mo ago
  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 5mo ago
    > 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 5mo ago
      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?