Tracking Issue for C++ Support as of release 2.1

[pabigot]

Issues that impact C++ support as of Zephyr release 2.1

Not yet worked or need review:

PR pending

• RFC: libc: thread-safe newlib #21519 providing thread safety for newlib ; pr libc: thread-safe newlib #21518

Resolved

• C++ usage #1205 involves need for explicit cast from void * to type * in C++ builds
• C++ 11 Support #4028 requests new/delete, vectors, RTTI, exceptions, static global dtor.
• C++ Support doesn't work #5695 mostly done, but blocked by address-of-temporary idiom not allowed in C++ #18551 ; pr treewide: avoid address-of-compound-literal idiom in headers #21397
• Unable to use C++ Standard Library #15603 cannot include_next stdhdr.h ; pr [Backport v1.14-branch] C++: fix builds with non-Zephyr toolchain #18552
• Build: C++ compiler warning '-Wold-style-definition' #16239 trivial? need to excluded -Wold-style-definition from C++ builds ; pr cmake: toolchain: generalize exclusion of CXX options #21398
• address-of-temporary idiom not allowed in C++ #18551 address-of-temporary idiom illegal in C++ ; pr treewide: avoid address-of-compound-literal idiom in headers #21397
• C++ New allocates memory from kernel heap #18990, relates to heap alloc with real libc++ ; pr Added option to disable Zephyrs C++ implementation #18464, [C++] Use malloc/free instead of k_malloc/k_free in operator new/delete #20678

[pabigot]

@galak @vanwinkeljan FYI.

[aescolar]

@pabigot Thanks for collecting this list. If you will be working on this towards 2.1 it would be nice if you could comment it in one of the coming TSC meetings so others are made aware of it.

[cfriedt]

A while ago I started looking at taking the conventional route to support std::thread, std::mutex, and std::condition_variable (basically wrapping all of it around pthread using gthr.h). Would involve minor modifications to the toolchain. Wrapping pthread requires pthread_create to accept a NULL attr, which requires dynamically allocated thread stacks, ..., dynamic kobject, heap allocator modifications. I'm hopefully at the bottom of that rabbit hole now 😅

A lot of it will be necessary without even using pthread, but wrapping pthread would be a useful shortcut even though it might add to the footprint. Definitely interested in helping out with this effort.

Also highly related is std::chrono, nanosleep, etc.

[nashif]

2.1 is long gone.