The keyword 'volatile' is used with member variables in several classes such as QTimeEvt. This is causing a large number of warnings when compiling as the newest standard of the language is depreciating the use of volatile.
Member variables affected are QTimeEvt::m_next, QTimeEvt::m_act and QTimeEvt:::m_ctr.
Is the use of the volatile keyword for optimization or for concurrency?
The volatile keyword is used for resons of concurrency. The variables (sometimes member variables of classes) declared as volatile are those that are potentially accessed by multiple threads.
I understand that volatile is deprecated in the latest C++20, so in the future the use of volatile will be scruitinized and potentially repaced with std::atomic<>, where appropriate. But for now, QP/C++ officially supports only C++11. This is also the standard still used in most embedded software, such as the latest CMSIS from ARM. CMSIS will generate even more "volatile deprecated" warnings than QP/C++.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also prefer std::atomic.
Notice small issue: most compilers what I work with do not support atomics for Cortex M0 (since it is not native supported).
However there is is simply workaround: just provide your own implementation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's what I thought. I had already been experimenting with redefining the member variables with std::atomic<> in place of volatile and I have not yet encountered any issues.
I'm using QPCPP on an ARM-cortex M0+ using g++ 12.1.0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
std::atomic<> is a complex, tricky, and not portable. You would need it only for concurrent sharing a given variable, which is very strongly discouraged in the QP framework. In other words, the whole framework has been designed to make it easier for you to avoid sharing (and the need for tricky constructs like std::atomic<>).
--MMS
Last edit: Quantum Leaps 2022-07-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The QP/C++ source code has been adapted to avoid all C++20 warnings of the type: "compound assignment with 'volatile'-qualified left operand is deprecated". The code updates were performed according to recommendations from the article "Modern Embedded C++ – Deprecation of volatile".
The updated QP/C++ code is available on GitHub in the interim release QP/C++ 7.0.1. Please check it out.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. I will test this interim release with my project.
My project is for the Raspberry Pi Pico, an ARM Cortex M0+ board. My development environment is Archlinux using CMake and arm-none-eabi-g++ version 12.1.0.
-A
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
QP/C++7.0.1 does eliminate all but two compiler warnings. I've attached qs_64bit.cpp with modifications to remove the last two warnings when compiling for c++20. The changes are based on the link you shared on Deprecation of volatile.
The remaining C++20 warnings have been fixed in qs_64bit.cpp as well as qutest.cpp. The updated version is available on GitHub in the interim release QP/C++ 7.0.1rc1.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The keyword 'volatile' is used with member variables in several classes such as QTimeEvt. This is causing a large number of warnings when compiling as the newest standard of the language is depreciating the use of volatile.
Member variables affected are QTimeEvt::m_next, QTimeEvt::m_act and QTimeEvt:::m_ctr.
Is the use of the volatile keyword for optimization or for concurrency?
-Archadious
The
volatilekeyword is used for resons of concurrency. The variables (sometimes member variables of classes) declared as volatile are those that are potentially accessed by multiple threads.I understand that
volatileis deprecated in the latest C++20, so in the future the use ofvolatilewill be scruitinized and potentially repaced withstd::atomic<>, where appropriate. But for now, QP/C++ officially supports only C++11. This is also the standard still used in most embedded software, such as the latest CMSIS from ARM. CMSIS will generate even more "volatile deprecated" warnings than QP/C++.--MMS
I also prefer std::atomic.
Notice small issue: most compilers what I work with do not support atomics for Cortex M0 (since it is not native supported).
However there is is simply workaround: just provide your own implementation.
That's what I thought. I had already been experimenting with redefining the member variables with std::atomic<> in place of volatile and I have not yet encountered any issues.
I'm using QPCPP on an ARM-cortex M0+ using g++ 12.1.0
Where do you have such a new g++ 12.1.0 from? Is there a binary distribution for Windows somewhere online?
--MMS
What do you want say? g++12.1.0 support atomic for CortexM0?
could you provide implementation of atomic on M0?
std::atomic<>is a complex, tricky, and not portable. You would need it only for concurrent sharing a given variable, which is very strongly discouraged in the QP framework. In other words, the whole framework has been designed to make it easier for you to avoid sharing (and the need for tricky constructs likestd::atomic<>).--MMS
Last edit: Quantum Leaps 2022-07-05
The QP/C++ source code has been adapted to avoid all C++20 warnings of the type: "compound assignment with 'volatile'-qualified left operand is deprecated". The code updates were performed according to recommendations from the article "Modern Embedded C++ – Deprecation of volatile".
The updated QP/C++ code is available on GitHub in the interim release QP/C++ 7.0.1. Please check it out.
--MMS
Thanks. I will test this interim release with my project.
My project is for the Raspberry Pi Pico, an ARM Cortex M0+ board. My development environment is Archlinux using CMake and arm-none-eabi-g++ version 12.1.0.
-A
QP/C++7.0.1 does eliminate all but two compiler warnings. I've attached qs_64bit.cpp with modifications to remove the last two warnings when compiling for c++20. The changes are based on the link you shared on Deprecation of volatile.
-A
The remaining C++20 warnings have been fixed in
qs_64bit.cppas well asqutest.cpp. The updated version is available on GitHub in the interim release QP/C++ 7.0.1rc1.--MMS
Thanks! It's working smooth as silk.
-A
Last edit: Archadious 2022-05-16
Last edit: Archadious 2022-05-16