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
In the implementation of complex, the Add, Sub, etc. for references are forwarded via clone() for values. This is very bad for types which are expensive to copy. In my example, I use Complex<Ratio<BigInt>>.
Can the code be refactored in such a way, that no clone() is necessary? I guess the different arithmetic operations have to be coded out and not forwarded.
I could try that, if there is no objection against that ...
The text was updated successfully, but these errors were encountered:
The main problem is that we added all of those implementations with just T: Clone + Num, and it's a breaking change to add additional constraints. To implement ops directly on references, we would probably want to use NumRef, NumAssignRef, and RefNum.
Note, Ratio also implements reference ops by cloning, which means that changing Complex alone wouldn't really help you.
I started looking at this for 0.3 (#70), but I'm skeptical. It requires a lot of code duplication on our part to directly implement each op with/without clones, and the additional T: NumRef + ... requirements end up propagating widely. The latter will affect all generic users too, sadly.
In the implementation of complex, the Add, Sub, etc. for references are forwarded via clone() for values. This is very bad for types which are expensive to copy. In my example, I use
Complex<Ratio<BigInt>>
.Can the code be refactored in such a way, that no
clone()
is necessary? I guess the different arithmetic operations have to be coded out and not forwarded.I could try that, if there is no objection against that ...
The text was updated successfully, but these errors were encountered: