I have noticed on the online documentation that Q_NEW in qpcpp is deprecated, but I have looked at the examples provided and it seems it is still widely used in the dpp program to create events to be posted via POST macro.
What would be the now recommended way to create dynamic events?
Also, another question: when using dynamic allocation for other things within a program when using the qp framework is there an alternative allocator and deallocators instead of the default malloc/calloc/realloc/free?
Regards
Last edit: mricciutelli 2024-07-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed, macros Q_NEW() and Q_NEW_X() have been recently deprecated. However, they have been so frequently used in the QP/C++ code that it will be a while until these macros will be phased out completely.
What would be the now recommended way to create dynamic events?
This information is provided in the documentation of the deprecated macros. Specifically, they are now replaced with function templates: QP::QF::q_new() and QP::QF::q_new_x(), respectively.
Also, another question: ... is there an alternative allocator and deallocators instead of the default malloc/calloc/realloc/free?
Absolutely not. Use of the general purpose heap is not recommended. Please see my old blog post "A Heap of Problems". Of course, if you wish to use the standard heap, nobody can stop you. In fact, you could dynamically allocate the memory for the event-queue buffers, event-pool buffers, etc. and pass this memory to QP. But this is generally a BAD idea.
--MMS
Last edit: Quantum Leaps 2024-07-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you Miro for your reply, I had misinterpreted the word 'equivalent' in the documentation ( I thought equivalent => also deprecated)
About the heap, I completely agree and I strive to avoid using dynamic allocation in any way possible, but I am in the situation where I need to use a couple libraries which i discovered to be using dynamic allocation and I was wondering how to make them safer to use!
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The use of the standard heap is a separate issue outside the scope of the QP framework. The framework does not use it internally and does not force the QP applications to use it.
So, if you decide to use the standard heap in your concurrent application, you take upon yourself all the responsibility to do this safely.
The fist approach I would consider is to safely encapsulate the heap inside a single Active Object. This is precisely what you should do with any other resource. Just don't share the heap among concurrent entities. This should be the easiest and the safest, but the rest of the project must NOT use the heap.
If you have to share the "libraries", however, you must protect the heap with a mutual exclusion mechanism. You could look into a mutex (if working with a traditional RTOS), or the selective scheduler-lock, if you work with preemptive QK or QXK kernels.
--MMS
Last edit: Quantum Leaps 2024-07-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear board,
I have noticed on the online documentation that Q_NEW in qpcpp is deprecated, but I have looked at the examples provided and it seems it is still widely used in the dpp program to create events to be posted via POST macro.
What would be the now recommended way to create dynamic events?
Also, another question: when using dynamic allocation for other things within a program when using the qp framework is there an alternative allocator and deallocators instead of the default malloc/calloc/realloc/free?
Regards
Last edit: mricciutelli 2024-07-11
Indeed, macros Q_NEW() and Q_NEW_X() have been recently deprecated. However, they have been so frequently used in the QP/C++ code that it will be a while until these macros will be phased out completely.
This information is provided in the documentation of the deprecated macros. Specifically, they are now replaced with function templates: QP::QF::q_new() and QP::QF::q_new_x(), respectively.
Absolutely not. Use of the general purpose heap is not recommended. Please see my old blog post "A Heap of Problems". Of course, if you wish to use the standard heap, nobody can stop you. In fact, you could dynamically allocate the memory for the event-queue buffers, event-pool buffers, etc. and pass this memory to QP. But this is generally a BAD idea.
--MMS
Last edit: Quantum Leaps 2024-07-11
Thank you Miro for your reply, I had misinterpreted the word 'equivalent' in the documentation ( I thought equivalent => also deprecated)
About the heap, I completely agree and I strive to avoid using dynamic allocation in any way possible, but I am in the situation where I need to use a couple libraries which i discovered to be using dynamic allocation and I was wondering how to make them safer to use!
Regards
The use of the standard heap is a separate issue outside the scope of the QP framework. The framework does not use it internally and does not force the QP applications to use it.
So, if you decide to use the standard heap in your concurrent application, you take upon yourself all the responsibility to do this safely.
The fist approach I would consider is to safely encapsulate the heap inside a single Active Object. This is precisely what you should do with any other resource. Just don't share the heap among concurrent entities. This should be the easiest and the safest, but the rest of the project must NOT use the heap.
If you have to share the "libraries", however, you must protect the heap with a mutual exclusion mechanism. You could look into a mutex (if working with a traditional RTOS), or the selective scheduler-lock, if you work with preemptive QK or QXK kernels.
--MMS
Last edit: Quantum Leaps 2024-07-12