Replies: 1 comment
-
Here is another idea: namespace Fw {
class ParameterHelper {
virtual Fw::SerializeStatus deserialize(const FwPrmIdType id, const Fw::ParamValid prmStat, Fw::ParamBuffer& buff) = 0;
virtual Fw::SerializeStatus serialize(const FwPrmIdType id, Fw::SerializeStatus &buffStat, Fw::ParamBuffer& buff) = 0;
}; Then, an implementer could implement it as a base class: namespace SomeNs {
class MyParameterHelper: public Fw::ParameterHelper {
Fw::SerializeStatus deserialize(const FwPrmIdType id, const Fw::ParamValid prmStat, Fw::ParamBuffer& buff);
Fw::SerializeStatus serialize(const FwPrmIdType id, Fw::SerializeStatus &buffStat, Fw::ParamBuffer& buff);
};
} Then, the autocoded baseclass could have: class CompBase:
...
CompBase(...., Fw::ParameterHelper& helper);
private:
Fw::ParameterHelper& m_paramHelper;
}; Then, the dispatch code becomes: FwPrmIdType _id;
_id = this->getIdBase() + PARAMID_PARAMETER1;
// Get parameter parameter1
this->m_param_parameter1_valid =
this->m_ParamGet_OutputPort[0].invoke(
_id,
buff
);
this->m_paramHelper.deserialize(_id,m_param_parameter1_valid,buff); |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
There have been discussions about delegating the deserialization of select parameters to outside libraries in the event they wish to keep their own copies and do their own deserialization.
Code changes:
Here is some sample generated code from
Ref/RecvBuffApp/RecvBuffComponentAc.cpp
,loadParameters()
function:If the FPP could have a tag to specify that a certain parameter is delegated, the above code could be replaced with:
where:
Would be overridden by the implementation component. The instance variable
this->m_parameter1
could be removed from the component.For saving a particular parameter, the code is currently:
The new function could be:
where:
Beta Was this translation helpful? Give feedback.
All reactions