25 ms·

I don’t think that you are limited regarding newer language features when you develop for embedded devices or limited in the use of more safety focused language

I don’t think that you are limited regarding newer language features when you develop for embedded devices or limited in the use of more safety focused languages. E.g. Ada, despite being in the older age for computer languages was specifically designed with embedded programming and safety features in mind and does this quite good. It also supports OOP if you want that sort of thing and more crucially has pretty good concurrency support build into the language while still being reasonably safe. With SPARK/Ada you even get a language variant that can be formally proven. To name some more modern use cases.

mumblemumble 6y ago
But this wasn't talking about using other languages with more of a safety focus. It was talking about using newer features of C++ that are meant to support safer programming. Most of these come in the form of abstractions with non-zero cost.
- AnimalMuppet 6y ago
  OK, but... I see three options. 1) Use the non-zero-cost abstraction to do X safely. 2) Write the equivalent abstraction to do X safely, which will cost you the time to write and will probably be buggier than C++'s version. 3) Don't do X. The fourth option - do X but in an unsafe way - should not be on the table for a professional developer. Now, C++'s philosophy is that you can't write your own thing to do X more efficiently than C++'s builtin version. They may not perfectly achieve that in all cases, but they come fairly close. That plus bugs means that I won't reach for option 2 unless I have really good reason to think I can do better. That leaves using the builtins to do X safely, or not doing X. At least that's how it looks to me...