Current view on use of C++ for Kernel/Driver development

[vChavezB]

I have seen the folllowing in the docs

I agree that the static order initialization fiasco is an issue. However, there are are a lot of benefits that the C++ language also has without the need to use classes and dynamic memory allocation. Are there any reasons as to why only the C language is accepted for this project?

My goal with this post is not to compare/discuss why C is superior to C++ or viceversa but to get a current view of why only C is accepted for the Zephyr OS project. Is it because of portability, scalability, toolchain compatibility, ..etc ?

Oh and dont get me wrong C is a good language but as an Embedded dev. C++ makes life less complicated at compile-time and can achieve similar or same results as C code. See https://www.youtube.com/watch?v=zBkNBP00wJE

[aborisovich]

Fully agree. As far as I saw there are currently works being done to implement C++ minimal library in the Zephyr SDK.
I think it's slowly going the right direction but there is enormous amount of work needs to be done to use C++ freely in Zephyr code
due to interfacing with many toolchains. Have a look at #45785 and generally "area: C++" label in issues. I hope we can use it someday. Also nice presentation here C++ in the World of Embedded Systems - Vladimir Vishnevskii - ACCU 2022 .

[autoany]

I am using subset of C++ for embedded development for more than 15 years, before C++11 was even a thing.
The problem with "Do not use C++ for kernel, ..." sounds more like "better be safe than sorry".

I have different point of view: C++ allowed me to write better (cleaner, readable, maintainable) code,
but I strictly disallowed any static inicialization (except pure copy that can now be achieved by constexpr), enforced this by linker script (limiting the size of inicialization table IAR compiler emits). Also disabled dynamic memory allocation, RTTI and even exceptions. No need for that in the kernel.
C++ also allowed me to create smaller, better optimized code. I admit that my view today may sound like over-optimization / over-engineering, but what once was about limited RAM/FLASH size is now about energy consumption (and response time even in battery-powered devices).

Limited C++ is better than C. Period. Limited C++, not full C++.

[marc-hb]

Limited C++ is better than C. Period. Limited C++, not full C++.

Yes, everyone agrees "Limited C++" is fantastic. The well known problem is: everyone has a different definition of "Limited". Sometimes that definition is only in their head.

Also, some "limitations" require using recent feature X instead which requires a "recent enough" standard and toolchain. How "recent"? C++11, C++20, ...? Again, everyone has a different opinion...

There is a now an effort "from the top" to formalize these definitions of "Limited" https://thenewstack.io/can-c-be-saved-bjarne-stroustrup-on-ensuring-memory-safety/

This looks promising but I'm not holding my breath, especially not for... years.

[autoany]

Yes, everyone agrees "Limited C++" is fantastic. The well known problem is: everyone has a different definition of "Limited". Sometimes that definition is only in their head.

https://en.wikipedia.org/wiki/Embedded_C%2B%2B
https://web.archive.org/web/20130521152331/http://www.testech-elect.com/iar/extended_embedded_c++.htm

Embedded C++ excludes some features of C++....
Some compilers, such as those from Green Hills and IAR Systems, allow certain features of ISO/ANSI C++ to be enabled in Embedded C++. IAR Systems calls this "Extended Embedded C++".[3]

I would be fine with just EC++, but got used to templates (and "multiple-inheritance" used for interfaces).