Closed qPCR4vir closed 1 year ago
For the compilation error, I think #665 is probably good if the behavior of ellipse
was satisfactory already.
By explicitly converting to int
, the behavior will remain the same while getting rid of the errors and also the warnings.
Unless rounding is desirable.
The code was introduced days ago. Is new. Where exactly in code the convertions from float to int are calculated may affect the quality of the ellipse and artifacts may arise. I have not checked that. I din't not run that code. It just compile.
Where exactly in code the convertions from float to int are calculated may affect the quality of the ellipse and artifacts may arise.
Yes, but the behavior would be exactly the same as Jinhao's code because all that's being done is making an implicit conversion into an explicit one, satisfying the compiler.
However, only @cnjinhao can say exactly if rounding would be desirable since he wrote it :laughing: Hopefully he will shine a light on this.
Hi, the ellipse
function is just a draft, I forget to check it before commit. I agree with @ventsin 's fix. The implicit conversion's problem in this issue is that int is implicitly converted to float. It causes following problem.
int x = 10;
float a = 1.5
int(x - a) = 8 //the distance from x is 2
int(x + a) = 11 // the distance from x is 1
The second issue, I think the call_safe_place is not a reentrant function, the after calling the function objects, the iterator i
may be invalid.
Hi, please, don't take too serious this - you may have better solutions.
The first is a variation on #664 and #665 becouse of compilation error. You may want to use std::round or simmilar if needed.
The second is a fix for a run-error (crash) that invalidate the
.end()
after an.erase()
. I don't know why, but it appear inrelease
anddebug
mode. The debuger showed undefinedend()
, which coincide with the documentation. I used trivial index. Not very elegant but works.