Is it recommended/practical to use C++ instead of plain C ?

[Event Horizon]

Hi,

i'm fairly new to microcontrollers, have experimented with Arduino in the past, but I'm an experienced C/C++ programmer
and wanted to ask your opinion about using C++ instead of C for ESP32-dev projects. Is it feasible to use classes, dynamic
memory allocation instead of constants and things like std::list ? How much does it affect performance and reliability ?
Would be nice to hear some opinions from experienced people.

cheers,
Event Horizon

[greengnu]

Absolutely. The esp32 is a little powerhouse, no problem using c++. You may want to override the new operator or use placement new to have more control over which ram you want to use (internal or external) though.

[PeterR]

Agreed, absolulely. C++ is the way!
Overloading new() and using a pool is a good idea but I have not found the need (used to have too on smaller PICs/M4s).
My engineering webpages show memory free/usage and maximum block size etc and I don't see much in the way of movement.
vectors, map, lists etc don't use much more memory anyway.

Most ESP libraries are 'C' and so you will have 'C' callbacks to class to deal with. We have C++11 though and so a light dusting of <functional> will sort out the C/C++ callback marshalling.
The main benefit I feel is that with C++11 the application logic can use tasks etc and still be portable (with some DI). This simplifies host testing and if like me you don't have JTAG then host testing really helps.

PS
18 years ago I was writting a control application in C++. That PC had 4MB FLASH, 8MB RAM @40MHz. Plenty of new/delete as had an LCD display. You can get a more capable ESP32 than I had on from a PC back then.

[Aussie Susan]

Some typical objections to using C++ instead of C are that handling the virtual calls etc takes additional time and memory, both of which are in limited supply on smaller microcontrollers.
One a PC that has memory measured in GBytes and clock speeds measured in GHz, these are not real issues. However on a device with a 40MHz clock and maybe as much as 1MB flash then it might be a consideration (depending on what you are trying to do).
Dynamic memory is another thing altogether though. Microcontrollers are often used in devices that are intended to keep running 'indefinitely' and therefore need to make sure that nothing stops them (hence WDT and the like). Depending on the dynamic memory allocation code you are using, you (as the programmer) need to be very careful to avoid heap fragmentation or you will suddenly find yourself being returned a NULL pointer which ultimately causes the app to crash/restart.
My personal opinion (and it is nothing more than that) is that dynamic memory allocation is something that should be avoided in embedded devices, and I've yet to find an example where various forms of static memory allocation cannot be used instead.
Susan

[Event Horizon]

Thank you alot for the answers

I'll always make limitations to the list sizes and string lenghts etc then, that should keep it from crashing.

[JoeThibodeau]

I am in the process of porting a C++ library to ESP32. So far it has been OK however I hit a run time error with a macro for looping which causes a Meditation Guru exception in the PThread class. The perks of C++ are welcome however I am not fond of the bloat associated with C++ in a resource constrained system and the ESP32 platform is a resource constrained system. An example: PThread is a wrapper for freeRTOS. Granted if the project you are working on does not have hard time constraints C++ may be a perfect choice. On the other hand using C++ can also become a bottleneck for development if C++ is required to complete the project. I have a project I am entertaining where C++ appears to be the bottleneck to productivity in a ARM environment. Making the choice to use C++ is not a casual affair in the land of limited resources.

[jimhelios]

I have used C++ successfully on a bunch of firmware projects in devices car less capable than the ESP32. As Susan said I do try to avoid dynamic memory allocation, however I often find that when I do use it, I just reuse the allocation and rarely have a need to free, thus avoiding heap fragmentation. You can also mitigate concerns about heap fragmentation by being careful about how big each allocation is, and using the same size whenever possible. Of course that can be a bit less efficient.

[PeterR]

I have a project I am entertaining where C++ appears to be the bottleneck to productivity in a ARM environment.

Why?

The extra memory needed is tiny. The team productivity gains can be huge (if the team have the experience etc). Next comes the cost/benefit review which will be a very personal affair.
The ARM environment may be a little different, generally less RAM/ROM and/or you have to fit more so cost. In high volume you would have to factor that in & some have used assembler rather than C for cost reasons.

the ESP32 platform is a resource constrained system. An example: PThread is a wrapper for freeRTOS.

Is that a formal fallacy? Wrapping freeRTOS with PThread does not make the ESP32 resource constrained, just someone came up with a good time saver.
There is an intersection between team performance gain (e.g. vectors, map, boost etc) and the drag on (marginal) extra resource use, the trade between generic pre-writen library vrs bespoke project 'wired for x' (& often buggy) library.
IMHO most resource concerns relate to the design architecture rather than the language. Design effort would be improved if you did not have to write so much code, i.e. use the C++ libraries!
I am on 22 tasks ATM (leavering other's libraries rather than writing from scratch) and I am not feeling the pinch (touch wood).

PS
I bet EventHorizon liked to poke sticks in ants nests as a child, may still do

PPS
The first C++ project I worked on was a disaster. Noone knew how to approach C++ except the man we followed, turned out he had a text book under his desk.

EDIT: Sorry but I am going to have to add a PPPS
PPPS
What's not to love about boost? Can anyone think of a basic problem not (for years & years) already solved by boost?
I just rolled boost endian for a serial stream, platform neutrality in a header, job done! Last week it was boost any for a type safe database (no RTTI in ESP). No resource drag(tiny blip on my radar), just works!
My biggest resource drags are webpages and then ano library. Last ano issue was SPIFFS &FATFS (CPU/throughput) the latter are IMHO algorithmic/implementation issues. So I switched to another library written in the dark ages, written with a keener sense.
So yes, you can get lazy/mess up in any language but C++ rocks (less than C# though & as I don't like tabs node over python).

[JoeThibodeau]

PPS
The first C++ project I worked on was a disaster. Noone knew how to approach C++ except the man we followed, turned out he had a text book under his desk.

Thanks for challenging my assertions. Yes you are right. C++ is a tight and useful language for mid size to large projects where design patterns are predominant in a design. Most of the work I do is low level embedded C on a variety of processors and not once have I been shorted on productivity because I didn't use C++. I have to adapt to my clients codebase and it's hard enough finding a team that doesn't write a 1 file 7000 line hackerware solution. Glory gone are the days of real software design. I do remember that period. It's fairly rare in embedded systems these days though I am sure that is changing.

If a application requires wide open throughput every cycle matters. That's why ASIO was designed for sound cards, to bypass the layers of software in Windows OS. It's similar if a OO design has many layers. The tradeoffs are flexible reuse and balls to the wall hard coded solutions. It really comes down to the application and the lifecycle of the software.

[PeterR]

I hear you; there is so much more depth to the question than the simple 'is C++ right'. If you are lucky that call depends on the resource you can leaver, often it depends on the mechanical/electrical manager who (to quote my teanage son) 'don't get it'.
Most teams I work within have a limited grasp of C let alone C++.
So we discuss an ideal which is something seperate to 'project optimum'

Not sure I understand the ASIO argument....
I tend to write a Linux style driver using 'C'. I then wrap with an abstract C++ interface & inject into the application logic. Now I can test off target with all the love that Visual Studio can offer. The 'C' driver must after all be integration tested so that's my abstraction layer. The call/memory expence is bytes.
I must say that on the ESP I have started using reflective/introspective techinques. This allows me to expose application details to a RESTful stlye api (using string properties names). This allows a pattern which exposes application behaviour and/or debug capability. Joy.
Suppose I am saying that with the ESP I have the RAM/CPU & I will use it!
(I stay grounded with my drivers but then, if you measure ESP's SPI implementation (or SPIFFS etc), you may choose to be 'not bothered')
IMHO the ESP drivers are wired for reuse/ease of use in most instances & definitely not speed. So if you want driver speed go ARM or roll your own. (In ESP defence, you have x2+ CPU and RAM over an M4 (but less DMA options)).