#189 QF_TICK_X naming change

[Aleksa Jonic]

Hi,

I was wondering why is the QF_TICK_X named like that. Throughout the QP we have functions like QACTIVE_POST that post with assertion and QACTIVE_POST_X that can post without. Why isn't QF_TICK_X the same in the sense that it should tick without a guarantee?

My proposition is to have QF_TICK_X be the same as QACTIVE_POST_X just for tick and the current version of QF_TICK_X can be named something else.

Aleksa

[Quantum Leaps]

Hi Aleksa,
The macro name QF_TICK_X() is the "extended" version of the (still available) macro QF_TICK(). The need for the "extended" version arose when a new parameter (tickRate) needed to be added to the macro.

So, here are the signatures of the QF_TICK() and QF_TICK_X() macros:

#define QF_TICK(sender_) ...
#define QF_TICK_X(tickRate_, sender_) ...

Regarding your suggestions for changing names around, please remember that QP needs to remain backwards compatible. The "extened" versions of other macros (e.g., QACTIVE_POST_X()) actually follow similar convention. The "extended" versions have generally more parameters than the non-extended versions.

In the end, I highly recommend that you refer to the documentation of the frameworks:

• QP/C Online Manual
• QP/C++ Online Manual

--MMS

[Aleksa Jonic]

Ok, it makes sense from the backward portability sense but why don't we have a tick function that won't assert on full buffer when we have the same functionality for posting and creating dynamic arrays?

In the function QF_tickX_ there is the call to QACTIVE_POST(act, &t->super, sender);

So my proposed function would just call QACTIVE_POST_X with the parameters passed by the QF_tickX_.

[Quantum Leaps]

This feature request is tabled for now because it breaks backwards-compatibility.
--MMS