Skip to main content
added 22 characters in body
Source Link
fceconel
  • 2.7k
  • 22
  • 19

I think other answers made a pretty good case for the pros and cons and decision factors, so I'd like just to summarize and add a few comments.

For small microcontrollers (8-bit), no way. You're just asking to hurt yourself, there's no gain and you'll give up too much resources.

For high-end microcontrollers (e.g. 32-bit, 10s or 100s of MB for RAM and storage) that have a decent OS it's perfectly OK and, I'd dare to say, even recommended.

So the question is: where's the boundary?

I don't know for sure, but once I developed a system for a 16-bit uC with 1 MB RAM & 1 MB storage in C++, only to regret it later. Yes, it worked, but the extra work I had wasn't worth it. I had to make it fit, make sure things like exceptions wouldn't produce leaks (the OS+RTL support was pretty buggy and unreliable). Moreover, an OO app typically does lots of small allocations, and the heap overhead for those was another nightmare.

Given that experience, I'd assume for future projects that I'll choose C++ only in systems at least 16-bit, and with at least 16 MB for RAM & storage. That's an arbitrary limit, and probably will vary according to things like the type of application, coding styles and idioms, etc. But given the caveats, I'd recommend a similar approach.

I think other answers made a pretty good case for the pros and cons and decision factors, so I'd like just to summarize and add a few comments.

For small microcontrollers (8-bit), no way. You're just asking to hurt yourself, there's no gain and you'll give up too much resources.

For high-end microcontrollers (e.g. 32-bit, 10s or 100s of MB for RAM and storage) it's perfectly OK and, I'd dare to say, even recommended.

So the question is: where's the boundary?

I don't know for sure, but once I developed a system for a 16-bit uC with 1 MB RAM & 1 MB storage in C++, only to regret it later. Yes, it worked, but the extra work I had wasn't worth it. I had to make it fit, make sure things like exceptions wouldn't produce leaks (the OS+RTL support was pretty buggy and unreliable). Moreover, an OO app typically does lots of small allocations, and the heap overhead for those was another nightmare.

Given that experience, I'd assume for future projects that I'll choose C++ only in systems at least 16-bit, and with at least 16 MB for RAM & storage. That's an arbitrary limit, and probably will vary according to things like the type of application, coding styles and idioms, etc. But given the caveats, I'd recommend a similar approach.

I think other answers made a pretty good case for the pros and cons and decision factors, so I'd like just to summarize and add a few comments.

For small microcontrollers (8-bit), no way. You're just asking to hurt yourself, there's no gain and you'll give up too much resources.

For high-end microcontrollers (e.g. 32-bit, 10s or 100s of MB for RAM and storage) that have a decent OS it's perfectly OK and, I'd dare to say, even recommended.

So the question is: where's the boundary?

I don't know for sure, but once I developed a system for a 16-bit uC with 1 MB RAM & 1 MB storage in C++, only to regret it later. Yes, it worked, but the extra work I had wasn't worth it. I had to make it fit, make sure things like exceptions wouldn't produce leaks (the OS+RTL support was pretty buggy and unreliable). Moreover, an OO app typically does lots of small allocations, and the heap overhead for those was another nightmare.

Given that experience, I'd assume for future projects that I'll choose C++ only in systems at least 16-bit, and with at least 16 MB for RAM & storage. That's an arbitrary limit, and probably will vary according to things like the type of application, coding styles and idioms, etc. But given the caveats, I'd recommend a similar approach.

Source Link
fceconel
  • 2.7k
  • 22
  • 19

I think other answers made a pretty good case for the pros and cons and decision factors, so I'd like just to summarize and add a few comments.

For small microcontrollers (8-bit), no way. You're just asking to hurt yourself, there's no gain and you'll give up too much resources.

For high-end microcontrollers (e.g. 32-bit, 10s or 100s of MB for RAM and storage) it's perfectly OK and, I'd dare to say, even recommended.

So the question is: where's the boundary?

I don't know for sure, but once I developed a system for a 16-bit uC with 1 MB RAM & 1 MB storage in C++, only to regret it later. Yes, it worked, but the extra work I had wasn't worth it. I had to make it fit, make sure things like exceptions wouldn't produce leaks (the OS+RTL support was pretty buggy and unreliable). Moreover, an OO app typically does lots of small allocations, and the heap overhead for those was another nightmare.

Given that experience, I'd assume for future projects that I'll choose C++ only in systems at least 16-bit, and with at least 16 MB for RAM & storage. That's an arbitrary limit, and probably will vary according to things like the type of application, coding styles and idioms, etc. But given the caveats, I'd recommend a similar approach.

Post Made Community Wiki