Grids can have two different storage orders. In Python and Fortran, that doesn't add any extra work because a numpy array with the correct order is made automatically, or the data is converted to Fortran order automatically. In C++ however, we expose the order and a pointer and let the user figure it out. If they're using an array library then probably that's what they need to create an array or array view, but if you want to extract values directly then you have to calculate the offset based on the shape and the storage order.
We could have a DataConstRef::value<Element>(args...) with any number of arguments that returns a specific value from the array, and that does the indexing internally. That would make it easier to get data directly.
There is a potential issue with the existing DataConstRef DataConstRef::value(std::size_t), we should make sure that there cannot be any confusion or overloading problem there. Having Element as a template parameter should help though.
Grids can have two different storage orders. In Python and Fortran, that doesn't add any extra work because a numpy array with the correct order is made automatically, or the data is converted to Fortran order automatically. In C++ however, we expose the order and a pointer and let the user figure it out. If they're using an array library then probably that's what they need to create an array or array view, but if you want to extract values directly then you have to calculate the offset based on the shape and the storage order.
We could have a
DataConstRef::value<Element>(args...)
with any number of arguments that returns a specific value from the array, and that does the indexing internally. That would make it easier to get data directly.There is a potential issue with the existing
DataConstRef DataConstRef::value(std::size_t)
, we should make sure that there cannot be any confusion or overloading problem there. HavingElement
as a template parameter should help though.