Hi,
We are considering to move the internals of LVGL to C++ but keep the API, speed, and size similar to the current.
It’d be awesome to know if you rely on a compiler (or environment in general) that doesn’t support C++.
Please, help our decision by sharing your case. Thank you! 
To better understand the requirements, if you can use only C, please write a comment and describe your situation.
0 voters
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.
I’m mainly using lvgl on ESP32, Teensy 3.6+, and FPGA targets.
I’ve updated the first post.
Why not other languages like Go or Rust?
There are compilers for 32 bit mcus in both languages. And I dont think LVGL was made for 8 bit MCUs
We want a language that is fully compatible with C/C++ infrastructure without requiring extra bindings.
I agree with you
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.
C++ should be available everywhere
Java is available everywhere, too.
No, i cant use java on 8 bit mcu
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.
@luka177 are you sure libc++ will be mandatory? with --specs==nano-specs my projects are built with ordinary newlib-nano.
Here are no wish to write in cpp style, only in “c with classes”.
No, i cant use java on 8 bit mcu
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++.
For me personally, C++ as a showstopper, though.
JW
Still what about size, wount lvgl become bigger?
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.
In general - no, size will be ~ the same.
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.