Hello everyone!
I'm wondering if it's a good idea to use some new TS/2a C++ features like coroutines.
Is there any plan to upgrade the GCC toolchain beyond the 8.4 version?
Or are you focusing on the LLVM port?
If so, what is the current stability of clang/LLVM toolchain regarding esp-idf core? Is it good enough to be used already or should I expect problems?
AFAIR gcc/clang strive to produce compatible object files so it might be possible to compile esp-idf using gcc and link it with the rest of the application compiled with clang. Did anybody attempt this?
Compilers and modern C++ features support
-
- Posts: 168
- Joined: Sun May 22, 2022 2:42 pm
Re: Compilers and modern C++ features support
Resurrecting this old thread…
By now ESP-IDF 5.2 (beta) is configured to use gcc 13.2.0, which implements a good bit of C++20 and C++23.
I wonder whether anyone had a go in using the new concurrency features. It is my belief that async algorithms using coroutines can lead to quite nice code when it comes to interfacing with hardware and/or networking.
That said, the open source coroutine libraries out there seem to be quite platform specific and there is nothing for FreeRTOS yet. I'll also ask on the FreeRTOS forum, but perhaps some ESP C++ guys can comment here.
By now ESP-IDF 5.2 (beta) is configured to use gcc 13.2.0, which implements a good bit of C++20 and C++23.
I wonder whether anyone had a go in using the new concurrency features. It is my belief that async algorithms using coroutines can lead to quite nice code when it comes to interfacing with hardware and/or networking.
That said, the open source coroutine libraries out there seem to be quite platform specific and there is nothing for FreeRTOS yet. I'll also ask on the FreeRTOS forum, but perhaps some ESP C++ guys can comment here.
-
- Posts: 1734
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: Compilers and modern C++ features support
I looked into gcc and coroutines some time ago, and determined that gcc's output for using coroutines (can't remember if RISC-V or Xtensa) had much more code, RAM & runtime overhead in it than I thought it would or was willing to accept. You may want to check that for your case.
Who is online
Users browsing this forum: No registered users and 138 guests