Currently there is:
- Heap storage, resizable: vector - Stack storage, resizable: static_vector - Heap storage, fixed size at runtime: dynamic_array - Stack storage, fixed size at compiletime: array - Heap storage, fixed size at compiletime: unique_ptr<array>
Why complicate a new type with this "have the size a template param" stuff when there already is a solution?
Fair enough! That sounds acceptable to me.
Yeah I know the interface won't be exactly the same. But I don't agree with "have the optimization applied". It is more than an optimization, its more like a separate type...
I tried working through a small implementation and this coincides with my findings perfectly. Definitely not worth it then.
Heap storage, fixed size at runtime: allocate_unique
(alloc, size, ...) Gives users everything they need for buffers. (They don't need a Container that is copyable).
Different classes for different usages. If a user needs just a pointer and a size, allocate_unique is perfect. dynamic_array is a Container. It's a higher-level of abstraction.
dynamic_array
could be dynamic_value
I think this is a strong design from an API perspective but I don't know if most users would be stoked on having to type the [] portion. It make sense for allocate_unique because you also use it for allocating single objects in addition to a contiguous sequence of them. allocate_unique is lower-level and more generalized whereas dynamic_array is higher-level and less general. I think the storage overhead is a mark against the dynamic_array but there's no cure for the disease that isn't just overall worse than living with it.
This actually makes sense, IFF the multi-dimensional case is possible. So if T[] and T[N] are valid, then T[N][M] should also be. This increases the scope greatly but has an incredible difficult questions to answer: What would operator[] return? I don't have a good answer...
You get T[N][M][...] support for free by using boost::first_scalar. If you check out some of the tests for dynamic_array you can see multi-dimensional arrays being tested. It's pretty trivial implementation-wise if you adhere to the idioms set forth by Core. In the case of dynamic_array, a reference to the value_type is returned. In the case of an array type, you basically wind up with: T (&value)[N][M][...]. References to array objects are never pretty in C++, unfortunately. The biggest problem with an approach like this is that you're now inter-mixing C-style arrays with a fully realized container. Maybe it'd be better if somehow we returned something like a mdspan. I'd be very interested in taking the container in a direction like that but I'm not sure how it'd pan out or if it'd be a strong violation of a user's expectations.