I wonder if creating "internal" variable names is preferable, in order to avoid name clashes.
When I started porting to this api, I immediately got a clash where I had to change my prop name to "EngineProps", since there already was a struct named Engine. The drawback is that I'd rather print "Engine" when presenting the properties.
rmt_PropertyDefine_Group(Engine, "Engine properties");
rmt_PropertyDefine_U32(FrameCount, 0, FrameReset, "# frames", &Engine);
An alternative would be just passing the name (not a pointer to a variable), allowing the macro to create
internal names for the variable:
rmt_PropertyDefine_U32(FrameCount, 0, FrameReset, "# frames", Engine);
E.g. the variables could be prefixed and end up like _rmt_prop_Engine and _rmt_prop_FrameCount.
What are your thoughts on this?
I wonder if creating "internal" variable names is preferable, in order to avoid name clashes.
When I started porting to this api, I immediately got a clash where I had to change my prop name to "EngineProps", since there already was a struct named Engine. The drawback is that I'd rather print "Engine" when presenting the properties.
An alternative would be just passing the name (not a pointer to a variable), allowing the macro to create
internal names for the variable:
E.g. the variables could be prefixed and end up like
_rmt_prop_Engineand_rmt_prop_FrameCount.What are your thoughts on this?