You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the fact that the assignment operator of matrix views does a shallow copy may come as a surprise to some users who may be used to other linear algebra libraries. i took a look at pre-existing LA libraries and Eigen, Blaze, xtensor, boost::ublas and dlib all do deep assignment. so code like this
is typically expected to modify m, rather than just overwrite the view temporary. we could protect against this specific case by making the copy/move assignment lvalue qualified. which would lead to a compiler error instead of silently doing the wrong thing in this case. but i don't think this is good enough to solve the issue in general, as the same issue would arise in this case
template <typename U, typename V, typename T>
voidmultiply_by_factor(U &&out, V const &in, T factor) {
if (factor != 1) { out = factor * in; }
else { out = in; }
}
where this would fail only if U and V are both views of the same type, and factor is equal to 1, making this potentially difficult to debug.
on the other hand, having copy/move assignment do a deep copy would go against what other stl view types tend to do, as std::string_view and std::span do a shallow copy. and may also potentially inhibit some optimizations since the type would no longer be trivially copyable. so a vector<matrix_view> might be less efficient, but from my experience views tend to be short lived and so this shouldn't matter all that much.
another solution would be to avoid using operator= at all, since it holds a special meaning in c++ that doesn't fit with what a user would expect in all cases. maybe an assign member functions or something like operator<<= would work better, but the syntax would slightly suffer for it.
The text was updated successfully, but these errors were encountered:
the fact that the assignment operator of matrix views does a shallow copy may come as a surprise to some users who may be used to other linear algebra libraries. i took a look at pre-existing LA libraries and Eigen, Blaze, xtensor, boost::ublas and dlib all do deep assignment. so code like this
is typically expected to modify
m
, rather than just overwrite the view temporary. we could protect against this specific case by making the copy/move assignment lvalue qualified. which would lead to a compiler error instead of silently doing the wrong thing in this case. but i don't think this is good enough to solve the issue in general, as the same issue would arise in this casewhere this would fail only if
U
andV
are both views of the same type, andfactor
is equal to1
, making this potentially difficult to debug.on the other hand, having copy/move assignment do a deep copy would go against what other stl view types tend to do, as
std::string_view
andstd::span
do a shallow copy. and may also potentially inhibit some optimizations since the type would no longer be trivially copyable. so avector<matrix_view>
might be less efficient, but from my experience views tend to be short lived and so this shouldn't matter all that much.another solution would be to avoid using
operator=
at all, since it holds a special meaning in c++ that doesn't fit with what a user would expect in all cases. maybe anassign
member functions or something likeoperator<<=
would work better, but the syntax would slightly suffer for it.The text was updated successfully, but these errors were encountered: