Hello,
I’m back on this subject long time after, but my 2 cts 
I like developing in C++ but definitively prefer to keep C as main target : I’m hacking on very slow machines (15+ year old PC, SBC like BananaPI, …) and, unfortunately, C++ compiler are pains on them due to resources usages (memory, CPU, …).
So I would prefer to have a lightweight as possible LVGL even if I wrote a C++ building when I develop for ESP32.
Bye
Laurent
I’m hacking on very slow machines (15+ year old PC, SBC like BananaPI, …) and, unfortunately, C++ compiler are pains
That’s an interesting point, having small footprint at build time rather than runtime. I wonder what are other reasons for voting no on C++.
I would guess that vast majority of CPU time is spent on inner rendering loops rather than the access of high level objects such as a chart or a label.
8 bit 16Mhz Arduinos for example use C++ with no problem (e.g. Serial.println()) so probably should be fine with the more powerful MCUs that typically run LVGL.
My 2c.
8 bit 16Mhz Arduinos for example use C++ with no problem
Yes, but almost (if not none) of arduino focused code is not using powerful part of the C++ like template, overloading, dynamic cast etc …
In the other hand, I’m able to run with decent performance C++ complex code on my 35 year Old Amiga1000 which is only powered by a 7.14 Mhz 68010 
, the only concern is to check carefully the stack. If performance lost is not very noticeable … memory consumption is (again if using C++ powerful features).
As another example : I created a fully object oriented library to handle 1-wire device, OWBus, and is known not working at last on Arduino UNO due lack to memory. And I used only overloading, nothing very sharp …
‘Responsible’ C++ embedded coding is definitely possible and I am sure the LVGL team will do it with resources consumption in mind.
I am not a C++ scholar but my understanding is that some of it’s features are basically syntactic sugar that is resolved at compile time and doesn’t have significant runtime implications. For example, function overloading where the function’s implementation is picked at compile time by name + signature rather than just by name.
As for function overloading on Arduino, I believe that is used regularly, for example in any HelloWorld that uses Serial.print(x). 
Personally I see C++ as a better C.
No, it’s not this kind of overloading but such one :
Class A {
virtual void func( void ){ ... };
};
Class B : public A {
void func( void ){ ... };
};
With virtual classes, a table of methods pointers is added which is duplicated in every objects with potentially methods signature. It’s worst as far I reminder with template.
Dynamic cast are also memory consuming.
200% agree with that 
Now for libraries like LVGL I would prefer something as light as possible to ensure the best coverage. Even if it means adding a binding for the higher level languages as I am doing with emToile.
I mean, since I’m using LVGL on ESP32s so I don’t really have to care about resources hence emToile (although it’s not really heavy), but I’ll be happy to have something super light the day I need it.
Portability would be greatly hindered by having a C++ codebase IMO.
I work with LVGL on a variety of different targets (PIC, STM32, ESP32, Linux) and I love how easy it is to integrate the library just about anywhere. Having to handle interop between C and C++ would be the first actual obstacle in doing that. While it’s true that most targets support both (although not all of them - I’m quite sure PIC compilers would prove difficult hosts) it’s always cumbersome to use two languages in the same project.
Full disclosure, I hate C++.
Why? You don’t have to use all the features it provides, just the ones that make sense. Some of them are very handy, for example namespaces.
Namespaces are admittedly useful, but I don’t think it’s the feature being pursued when discussing whether to move to C++. If they were it simply would not be worth it to change language just to be able to split modules more cleanly. C is all around simple to work with, moving to C++ would spoil this.
On a side note, I fear C++ is being considered to leverage on the inheritance system, based on the misconception that class-based object oriented programming is a good fit for UI programming. I believe the current system based on void* pointers to be much more suited for the job than any hierarchical class tree.
If the goal is to work with a more modern language there are better options IMO, although I must admit none of them is ready now like C++. Someone already mentioned Rust which would be quite a jump from C; I’d like to point to Zig: it has yet to reach a stable/production ready release, but is a very promising project. It also has the short term objective to compile to C, which would guarantee compatibility with all targets.
LVGL widgets are already object-oriented in terms of the way its APIs work, so I’m not sure what you mean by this. For example, a container inherits from a base object, a button inherits from a container, etc.
I’m pretty sure someone could rewrite LVGL to use C++ classes with minimal changes to the architecture.
Since the LVGL team is involved with vendors such as NXP, this is a question that they may be answer. How open are their customers who use UI for C++ only project? They may have good information about their market.
I also hear about missing, buggy, or limited embedded C++ compiler features.
I’m not sure we can identify a subset of C++ features that are surely working on all platforms where C works.
LVGL is good because its working on C. Just C. I am using it with stm32 (on C) and SBC`s (linux framebuffer on C)
As for me it will be more complicated to use (now lvgl can be ported on even door handle) and with c++ i think not.
Main thing i would improve - more widgets and less space requirement for projects.
Maybe i am !douing something wrong! but !full! library consumes 100kb of free space. And it forces me to find the way to use external memory where i dont want to.
if lvgl became mandatory c++, i will stay on last C version.
even if there some ugly places - they works fine, i like to work with this library - almost all seems on its places. Actually its the best product ive ever seen (usability), this library became most recent for me.
I see it the same way.
Wow, thank you! 
Somehow in the past few days, I got unexpectedly many positive feedback. So happy.
I have updated to v8 now and want to try emToile also. I’m using Mbed-OS, which has also a C++ API. Many objects have members that call C functions, because underlying frameworks are using C. I can see no big performance penalty, the compiler is optimizing a lot.
Lvgl. is using an OO approach already, but without type safety. You can call every function on a lv_obj, regardless if the object does support it or not. With C++ you create methods that work with a particular object and that makes it type safe. Another benefit is the Intellisense that can show the methods and properties of a widget.
For me, C++ is much more than syntactic sugar.
I definitely agree to have an optional C++ binding to LVGL but keep the core in C for maximal compatibility.
It’s a different topic but this video was created about the very first version of LVGL which wasn’t public and I’m not sure I still have it 