Re: Yet Another Container: DynamicArray

From: Christian Mazakas (christian.mazakas_at_[hidden])
Date: 2020-01-26 00:26:51

> 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<T[]>(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<T, A>  could be dynamic_value<T[], A>

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.