4 ms·
Most places I’ve done embedded dev at have been C or C++. Actually all, with some Lua or assembler sprinkled in. Debugging C++ when your compiler for weird tar
by osivertsson 5y ago
Most places I’ve done embedded dev at have been C or C++. Actually all, with some Lua or assembler sprinkled in.
Debugging C++ when your compiler for weird target (SH4, or worse) contains bugs, or when you have some relaxed memory consistency model, is quite a challenge because mapping C++ to assembler is definitely non-trivial. C, even with heavy optimizations, is a breeze comparatively.
I would happily join a team that uses Rust in an embedded setting. It shows that they care deeply about doing better than average, and that probably means they are better than average in everything.
- ncmncm 5y agoMapping C++ to assembler is exactly the same as mapping C to assembler, for those operations the languages share. If you are coding reasonably, there aren't any other operations that happen at runtime. C++ does its heavy lifting, preventing bugs, at compile time.
- osivertsson 5y agoFor sure C++ does a lot of heavy lifting at compile time, which shows in poor compile and link times, although it is less of a problem today than 25 years ago since hardware performance has increased. I don’t agree that C++ automatically prevents bugs, even though using e.g. RAII can help a bit and leads to maintainable code. If you use exceptions (you probably shouldn’t) there is one more code-path out from your code. That together with constructors/destructors being called and using STL instead of more trivial data-structures often leads to a lot bigger assembler output to trawl through if you need to.
- ncmncm 5y agoC++ doesn't "automatically" prevent bugs. You have to actually, you know, use it. By STL I guess you mean std::string and std::vector. That is wholly optional. I would not use those in a small embedded project, except maybe at startup, and then with a custom, non-freeing bump allocator.