To make things clear, we are not planning to rely on any C++ features that are known for excessive code size or bloat. Performance should be similar or identical to the current version - this is mainly a syntactical change that would get rid of some ugly hacks in the current codebase.
Anyone, who can use C only, could you explain your situation? At first glance, C++ should be available everywhere (for any MCU, able to run LVGL). I’d like to understand your cases.
I can use lvgl C only. I am working on dualboot solution for android devices, https://github.com/Android-Boot-Manager and in some cases we replace phones bootloader. For example on Volla Phone we have 1 mb partition for lk (little kernel) based bootloader. We have a lot of problems fitting evrything there, and there is no space for libc++. But libc is there, bcz lk needs that.
Oh, sure you can, just google e.g. AVR JVM. And you could, some 20 years ago, too; e.g. using the TINI stack in Dallas Semiconductor DS80C380.
But that’s not the point.
The point is, that a tool being available does not mean it’s suitable. There are many, MANY reasons to use or not to use a given tool/feature.
C is the least common denominator for microcontrollers in particular, and LVGL being in C is a precious asset, increasingly rare these days.
OTOH, I understand Gabor’s desire to migrate to C++ - at the end of the day, he painstakingly reproduced some of the features which would come automatically with C++.
It’s likely to not change that much in either direction, since the existing “fake” objects would be replaced by standard C++ logic. However, I haven’t done any profiling of C++ classes to know the exact cost compared to our current solution.
Having a proper C++ API will make using LVGL. For example, I wouldn’t need to remember if method X comes from obj or from Label. Just typing my_label.set_pos in the IDE and the autocompletion will find it.
BTW, the limits that I face are around RAM and screen update speed (number of pixels to push to the TFT controller) and not that much around ROM, code size, or computation speed.