Could an xtensor_adapter with ownership be an xtensor?

[emmenlau]

I'm sometimes running into problems with the number of dedicated classes that xtensor provides. Currently its a slight problem for me that adapt() provides an xtensor_adapter instead of a plain xtensor. I was wondering if the dedicated type is required?

For the case where xtensor_adapter takes ownership it seems there may not be too much of a difference between the xtensor_adapter and a plain xtensor, or am I on the wrong track?

And for the case where ownership stays with the original provider, I understand that the dedicated type is required to avoid double memory deletion, is that correct? But could this work like an xview or an xtensor with a reference count plus, one to avoid the final memory deletion?

Please forgive if I'm completely on the wrong track here. I was just using similar adapters from cv::Mat and QImage in the past and they avoid the dedicated type, albeit they do not provide the extensive options that xtensor has.

[SylvainCorlay]

I don't think this is really possible unfortunately. These expressions have very different semantics.

• The xtensor_adaptor with ownership will use a bare delete to de-allocate the pointer that it takes ownership of, while xtensor will rely on the underlying storage container which may be using a custom allocator, or have very ad-hoc logic (xtensor is just a typedef on xtensor_container which is parameterized by the storage type).

[emmenlau]

Dear @SylvainCorlay , thanks for the clarification, I checked the code and I understand it better now. So the default memory container is std::vector, and since we can't construct a std::vector with our own memory pointer there is not even a chance to create an xt::xtensor from existing memory.

However if I understand correctly then it might still be possible to use xt::xtensor_container with a different memory container, that can (optionally) be constructed from existing memory? Do you know if this idea is futile? Is it possible to write an adapt method that can pass a pre-sized memory container to xt::xtensor_container, or will xtensor_container always try to resize the memory container itself?

[JohanMabille]

Actually we could "merge" the xtensor_container (resp. xarray_container) and xtensor_adaptor (resp. xarray_adaptor) classes. An adaptor would be a container parametrized with a reference / constant reference on a STL-like container, while a N-D container would hold the underlying STL-like container. Although that would reduce the amount of code and number of classes in the library:

• xtensor would still be an alias on xtensor_container parametrized with the default container and would not be able to be constructed from a different kind of container.
• it would still be easier to adapt a memory buffer with the adapt method rather than instantiating by yourself an xtensor_container / xarray_container with the right template parameter.

So I'm not sure that this would simplify things for you (but it would for us ;)).

Is it possible to write an adapt method that can pass a pre-sized memory container to xt::xtensor_container, or will xtensor_container always try to resize the memory container itself?

If we merge xtensor_container and xtensor_adpator, the behavior of an xtensor_container parametrized with a different container type (reference or C-style array for instance) would be the same as the one of the current xtenosr_adaptor: no resize upon construction, but resize upon assignment.

If you want to prevent resizing of the underlying 1-D container, you have to pass a dedicated type that cannot be resized (such as xbuffer_storage for instance) to the xtensor_adaptor (potentially future xtensor_container constructor. So basically, preventing resizing and using the same template class for xtensor and xtensor_adaptor are orthgonal problems.