No-one should need to listen to a bunch of fanatics. Different problems are have different constraints. Some problems are easier to solve using a different formalism than some other. People try to sound like Herb Sutter or Stroustrup when peddling their "best practice" advice after looking at a few lines of code and deciding it's not to their liking. Sutter and Stroustrup usually have a grasp of the higher level context, while random best practice commisars in the web, seldom dont.
Since C++ contains so many footguns the charitable explanation is that they grasp to the only way of coding they can hold in their head.
Damn the establishment! C++ offers a refreshing multiplicty of styles of implementation. ML style for data transforms, lispish dynamic lists for parsers, vanilla object style for some problem domains, relational style with structs of indices for others. Note: solutions of these styles can be wrapped in a nice cplusplushy interface but if one starts to solve the problem from the point of view of designing the class hierarchy rather than looking at the data and transforms required often leads to a technically inferior dessign (by which I mean - my designs became much better after I understood to focus on the latter and not the former). One needs to be strict, yes, but the strictness needs to be on a closer-core-cs-concepts level and not on the class design level.
Just wrote a parser in lisp style C++ and loved it (and yes, there were enough constraints to limit C++ as the only language).
That might be a bit bad example, because IO pin control is usually compiled to just one or at most a few machine instructions. IO pin control for those is often a macro or intrinsic, not really a library.
Sometimes there's no runtime, other than what you implement. That's true bare metal.
Yes well um no, that only happens in a select few embedded bare metal projects, and usually only the ones with fairly beefy processors or large code bases running on them. Once you contemplate in putting a library layer for your project you might as well put down a full rtos or linux, taking us out the focus of this discussion which is bare metal C++ programming.
>> Besides not all processors offer MMIO...
I don't understand what point your trying to make? The vast majority of embedded processors these days offer memory mapped IO, at least so in the ARM set of processors. And if not all processors offer MMIO, so what, what are you trying to say?
>> I see, they always write everything from scratch.
Embedded developers, yup pretty much... :| Most projects just copy and pastes the OEM's sample code or previous projects driver code and work from there.
>> Then you need to wrap the Assembly instructions out* / in* into C functions or sprinkle all the code with inline assembly since libraries aren't used.
I have never seen that being done in the last 10 years except for the startup sections on processors setting up the ISR / clocking / co-processors etc.
A lot of embedded code uses macros to deal with the register/configuration handling, rather than functions. I've seen loads of inline assembly in #defines.
No-one should need to listen to a bunch of fanatics. Different problems are have different constraints. Some problems are easier to solve using a different formalism than some other. People try to sound like Herb Sutter or Stroustrup when peddling their "best practice" advice after looking at a few lines of code and deciding it's not to their liking. Sutter and Stroustrup usually have a grasp of the higher level context, while random best practice commisars in the web, seldom dont.
Since C++ contains so many footguns the charitable explanation is that they grasp to the only way of coding they can hold in their head.
Damn the establishment! C++ offers a refreshing multiplicty of styles of implementation. ML style for data transforms, lispish dynamic lists for parsers, vanilla object style for some problem domains, relational style with structs of indices for others. Note: solutions of these styles can be wrapped in a nice cplusplushy interface but if one starts to solve the problem from the point of view of designing the class hierarchy rather than looking at the data and transforms required often leads to a technically inferior dessign (by which I mean - my designs became much better after I understood to focus on the latter and not the former). One needs to be strict, yes, but the strictness needs to be on a closer-core-cs-concepts level and not on the class design level.
Just wrote a parser in lisp style C++ and loved it (and yes, there were enough constraints to limit C++ as the only language).