It is the standard header. It has standard \params for function parameters and \retrurn for return values. So it has all you want, regarding output and input. All standard cpp headers are like this.
These are not placeholders but helps to find next command line argument definition. Since the type of arguments are different and for different type there should be different implementation, it's not easy to find each.
All of these "engineering" build flags are sometimes commented/uncommented depending on what we're building for. e.g. RM46_EVAL_BOARD_TARGET is uncommented when I need to make a build for Behrouz to test on his eval board. As the need for some of these goes away, I remove them.
I don't know why I should use dynamic_cast and have an if around the cast. What is the point? What do I gain by doing so? I'm sure checking everything in compile time is much more safer than in run-time waiting for the code to be executed and then handle the exception. What is the advantage of the dynamic_cast over the static_cast. they do the same thing if can successfully doing it in different situation.
Dara will instrument the Bamboo build across all software code bases to check for all manual code coverage comments and create a summary of it. Then, to be able to pass through the Phase II gate of our R&D development process, we will all review one by one each of these exceptions in a phase gate review meeting and make sure they don't need further testing before doing the official release candidate.
It's flow that we would expect from displacement of each rotor turn based on measured motor speed. Motor speed can be converted to rotor speed, then rotor speed to flow.
This is what looks best at this time. Flow sensors tend to be pretty accurate if you average over a long time, but very choppy in the short or even medium term. However, if I extend the filter time to 10 s, then the control interval has to be at least 10 s as well. I've discussed with Blaine and Nick to verify this is ok. I think we don't want the blood and dialysate inlet pumps to be very reactive anyway - the treatment lasts 1-8 hours, so we can start with an estimated PWM that will be close and then take a minute to gradually improve on that estimate with our slower control.
Don't we not know the true type of vData even at runtime? So, what is the advantage of static_cast being used if it only checks the type at compile time? With dynamic_cast doesn't it return null if it doesn't contain the type casted, so you just add an if statement checking whether it is null or not to know for a fact that you're cast was successful
static_cast will be evaluated at compile time and if there is any issue casting it will not even build. dynamic_cast will do it at run time which is hard to handle that exception, I would only use it when I need to cast an interface of a .so file load at run-time or so.
I think static_cast is much more safer than dynamic (specially in our case.)
You are running release
CR4.8.14
FE4.8.14
(20240111091859 2024-01-11 09:20),
please report your release number when reporting bugs.
