Finally I managed to read your code, so I can give you the full feedback. I
have an overall idea of how your proposal can be changed, but I want to
respond to your comments individually first.
- it is true that several functions that one might expect to be in the
interface of a math object only conditionally make sense if the underlying
container supports dynamic memory allocation, but this can be applied to
any object, such as an STL container. There are circumstances that lead a
user to use a static std::list or std::vector, but this does not justify
the creation of two identical containers that differ only in static or
dynamic memory management. If this were done, the STL library would be much
bloated, making the existence of the allocators partly useless: since the
allocator is used to abstract the memory management (or rather, it is a
handle to the memory), you can implement an allocator that is essentially a
handle to a static array. In this way, although it is not very elegant, it
is possible to create a custom fixed_vector or a fixed_list by passing,
respectively, a static allocator to a std::vector or a std::list. It is up
to the user to avoid calling member functions that can lead to memory
resizing, such as reserve(), otherwise a std::bad_alloc is thrown, as if a
simple dynamic allocation failed.
- if you want to adopt a container adapter interface, as already present in
all container adapters, you create two overloads for the constructors, one
without an allocator and the other with an allocator (if the
std::uses_allocator type trait is true).
- although already-existing containers do not support efficient
multidimensional resizing, it is still possible for the user to implement a
custom container. It depends on what the user thinks.
But your comment "existing containers don't support efficient
multidimensional resizing" is precisely the key point: over the guarantee
of a complete interface for performing linear algebra operations, does the
matrix container offer advantages in terms of flexibility and performance?
In my opinion, creating a matrix container, whose implementation takes the
best features between std::valarray and mdarray would be the best. Without
introducing new containers or container adapters, the matrix container
could fill some of std::valarray's shortcomings by providing an interface
that allows the user to perform easily simple and complex linear algebra
operations on N-dimensional arrays.
If that is okay, you can present a draft of the matrix container,
especially highlighting the benefits of linear algebra operations and
memory management.