You bring up a good point on the static and dynamic memory allocation that I wouldn’t mind more perspective on. I admittedly haven’t looked much into the std::flat and std::flat_map interfaces for; however, I’ve looked at the P1684 mdarray proposal. Perhaps, more iteration is needed on mdarray to do as you say. It is also interesting to note the container adaptors require a sequence container, which std::array only partially meets requirements for.

There are several issues which arise from trying to entirely abstract the memory management into an adaptor like interface.

- Several functions which one might expect to be on the interface of a math object only conditionally make sense if the underlying container supports dynamic memory allocation. This includes construction with allocators, resize, and reserve.

- If one wanted to completely remove allocators from the public interface then you’d construct using the underlying container, rather than being able to simply specify size and possibly capacity. So what could be "dr_matrix( size )” now becomes “matrix( container, size )”. More so, if the extents are entirely static, then “matrix( container, size )” becomes redundant compared to what could be just “fs_matrix()". Trying to mesh all this into one class causes interfaces to feel more complicated than they ought to be.

- Existing containers don’t support efficient multidimensional resizing. Consider a 2x2 matrix with a 2x4 capacity using a std::layout_left policy. For efficient resizing, I’d want 2 elements, followed by 2 uninitialized elements, followed by 2 elements, and then 2 more uninitialized elements. Within each row, I’d want contiguous memory; however, in linear memory, I’d have discontinuous blocks. That cannot be managed by something like std::vector. The alternative is to force everything into one contiguous block and thus every resize results in a lot of copying and can become expensive (which kind of feels like it defeats the point of reserving in the first place). Note, the mdarray proposal does briefly mention resizing along the same lines, but provides no mechanism for doing so nor discuss how it could be achieved.

These complications drove me to keep separate implementations with clearer interfaces, but I’m happy to hear other thoughts and tinker with different directions.


> On Apr 17, 2023, at 2:42 PM, LoS via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> The underlying idea appeals to me.
> In the next few days, I will read your proposal in more detail to give you a complete feedback, but for the moment I will focus on the basic design.
> I think you are bitting off more than you can chew, among new classes, new functions, and new concepts. Your implementation would be great for a custom library that provides containers for linear algebra operations, but it is too restrictive and full-bodied for an update to the C++ standard.
> I do not agree with introducing new classes that involve direct memory management, in particular if there are two versions that provide static memory and dynamic memory separately, because I believe they are redundant with the already-existing STL containers, such as std::vector and std::array (it is effectively used in your implementation of fixed size classes).
> I think you may avoid this by creating adapters, like std::flat_set / std::flat_map, that provides different interfaces to perform linear algebra operations and do not worry about anything at lower level.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals