C++ Roadmap

[stephanosio]

This issue describes the future plans for the C++ support in the Zephyr RTOS.

Tasks

• Unify C++ source and header file extensions (Unify C++ source and header file extensions #44196)
• Establish C++ coding guidelines (Establish C++ coding guidelines #45195)
• Refactor C++ support in Zephyr (Toolchain C++ headers can be included when libstdc++ is not selected #36644 (comment))
• Add native Zephyr support in the libstdc++ (Add Zephyr-specific target for toolchain components sdk-ng#350)
• Add comprehensive C++ library testsuite
  • shall test the functional requirements of all supported C++ libraries (mainly libstdc++ for now) to ensure that the C++ library meets the Zephyr expectations.
  • shall have common codebase for testing different C++ libraries (focus on testing standard C++ features).
• Add std::mutex, std::condition_variable, std::counting_semaphore, and std::binary_semaphore support (via gthr-posix.h, see below)
• Add std::thread support (via gthr-posix.h, cpp: thread: support for std::thread, std::mutex, std::condition_variable, etc #43729)
• Add std::async and std::future support C++ std::async and std::future support #31559

Resources

• Issue describing the status quo of the C++ support in Zephyr: C++ support in Zephyr #31281

[stephanosio]

cc @cfriedt @yperess @alexanderwachter

[XenuIsWatching]

any reason why std::condition_variable, std::counting_semaphore, and std::binary_semaphore isn't included?

[cfriedt]

any reason why std::condition_variable, std::counting_semaphore, and std::binary_semaphore isn't included?

Good call - definitely on the roadmap. I updated the description slightly. A lot of things we would get "for free" with #43729.

Big blocker for std::thread (at least dynamically) is #44397 (and having time to work on upstream)

[aborisovich]

Might be a chance to review existing C style rules.
I am talking about positioning "*" on the "right side" of the type definition.
For C nobody cares where it is positioned (shamely), in C++ it starts to make more sense with introduction of reference types.
Basically it should be:

When & and * characters are "glued to the left" side during type declaration
(following are standard rules - note how other specifiers behave - everything type related to the left then variable name on the right, we don't do like in the line 0 here:

C++ brings more to typing on the table. Please consider this change it really makes sense.

[stephanosio]

As far as C is concerned, int * is the only correct form because:

int *a, *b;

For C++, we could potentially adopt int* and ban multiple variable declarations in one line.

[aborisovich]

As far as C is concerned, int * is the only correct form because:

int *a, *b;

For C++, we could potentially adopt int* and ban multiple variable declarations in one line.

I've just read about it... It is so "broken". Both in C and C++...
Existing style makes some sense then.
Seems like this "problem" carries over to multiple reference types inline declaration.
int a = 1, b = 2, c = 3;
int& c = a, &d = b, &e = c;
However I've never seem this syntax in C++ production code until @stephanosio brought up this subject.
And I think I've rarely seen anyone declaring reference types like
int &a = b;
Or going further:
int &&a = b;
Maybe I'm too young and just haven't seen enough in my life but it seems to me that the very same problem exists in C++ and it is mostly resolved by "don't use that confusing many inline syntax"...
I still believe that my previous post brings more intuitive code at the only cost of that multiple inline definition.

[dberlin]

Just to try to help a little i can confirm that hacking up the c++conf.h and gthr.h for the compiler is sufficient to make shared_mutex/condition_variable/etc compile fine without changes.
In particular, c++conf.h (for the toolchains in zephyr-sdk 0.14.2) just needs needs:

#define _GTHREAD_USE_MUTEX_INIT_FUNC 1
#define _GTHREAD_USE_COND_INIT_FUNC 1

(to not use the initializers which zephyr doesn't support)

and gthr.h needs:

#if _GLIBCXX___ANDROID__ || CONFIG_PTHREAD_IPC
#include <bits/gthr-posix.h>
#else
#include <bits/gthr-default.h>
#endif

(I have no earthly idea why it's gated on ANDROID and not a GLIBCXX__PTHREADs macro or something)

to use gthr-posix.h, you need
`CONFIG_PTHREAD_IPC=y

CONFIG_POSIX_API=y

CONFIG_APP_LINK_WITH_POSIX_SUBSYS=y
`

With these changes, the compiler will compile shared_mutex/etc fine.
(it appears CONFIG_PTHREAD_IPC should force CONFIG_POSIX_API to 1, but it doesn't)

Note that condition_variable (and i suspect other stuff) compiles but doesn't link.

This is because all of this requires the libstc++ be compiled with threading support (and the config change), and at least the ones in zephyr-sdk (and my NRF sdk) are compiled both single threaded and obviously without the gthr changes.
The above changes really have to be made in the right toolchain configure bits/etc, and the toolchains changed to enable threads.

It's possible but a bad idea to do it without changing the threading model on the toolchains:
I was a GCC/LLVM hacker for 10+ years, and saw it done, but it is a really bad idea:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html#manual.intro.using.concurrency.thread_safety

agrees, saying:
"multithreaded C++ application are only supported when libstdc++ and all user code was built with compilers which report (via gcc/g++ -v ) the same thread model and that model is not single."

[dberlin]

If you'd like to play around with a working mutex/condvar/shared_mutex, the following will let you do it.
You have to set the POSIX options i mention in prj.cnf.

Then unzip
stl_threaded.ZIP
into the project root, and then add the following to CMakeLists.txt

FILE(GLOB stl_threaded_sources lib/stl_threaded/*.cpp lib/stl_threaded/*.c)
target_sources(app PRIVATE ${stl_threaded_sources})
target_include_directories(app BEFORE PUBLIC "lib/stl_threaded")

This will ensure the bits/c++config.h changes override the toolchain ones.
The condition_var/mutex source is just the correspnding ones for the toolchain from the sdk-ng project.

I took a quick pass at hacking the toolchain to enable threads (IE CT_THREADS_POSIX=y) and change the os defines, but i'm still working on getting the environment to be the same as the CI workflow uses (I tried using act to execute it locally, and even if i revert back to pre-s3-download versions, still no luck).