Currently, we still allow matrix_opt pass by value.
However, in oneMKL implementation, we have get_matrix_handle(m); it traversed until it is matrix_opt and pass it to create_matrix_handle.
Take scaled_view(2.0f, m) as an example,
get_matrix_handle(scaled_view(2.0, m))
-> get_matrix_handle(scaled_view(2.0, m).base()) base will give a new object and will create handle in that new object.
The new object will be destroyed when it return, so the handle will also be destroyed.
two ways
- always use smart pointer to handle matrix opt and others (to keep consistent), but I think previous discussion tend not to use smart pointer.
- disable matrix_opt copy constructor/assignment and take reference for constructor/return reference of base(), which might need to change all base() or corresponding function? However, it might introduce some potential wrong access to destroyed object when user clean their matrix opt but still used the view on top of it
Currently, we still allow
matrix_optpass by value.However, in oneMKL implementation, we have get_matrix_handle(m); it traversed until it is matrix_opt and pass it to create_matrix_handle.
Take scaled_view(2.0f, m) as an example,
get_matrix_handle(scaled_view(2.0, m))->
get_matrix_handle(scaled_view(2.0, m).base())base will give a new object and will create handle in that new object.The new object will be destroyed when it return, so the handle will also be destroyed.
two ways