On Wednesday, 24 January 2018 at 04:15:27 UTC, Mike Franklin
wrote:
On Wednesday, 24 January 2018 at 03:46:41 UTC, lobo wrote:
Well if your embedded device has all that on it you should be
sitting on an OS with proper memory management support.
I don't see how the OS can help if the underlying hardware
doesn't have an MMU. That being said, admittedly, the more
capable microcontrollers do have an MPU that can be configured
to throw a hardware exception.
OK I'll state here that personally I don't agree with the
segfault argument if the nullptr access can be detected at
compile time. Anything that can be done at compile time should
not be pushed out to runtime.
That said you can architect code so that nullptrs go away and the
MMU is not necessary. E.g. no pointers and no allocations after
main() are just two of a number of steps you can take. Good
engineering works; in the 10yrs I've been with the Health Care
Devices group we haven't had one memory corruption issue in a
critical component. The last memory corruption issue we had in
non-critcal was 4yrs ago, in older C++ code. Memory corruption
really is becoming a thing of the past in modern C++.
Now the biggest problems for us are security because everything
has to be internet enabled!
We don't use D, it is all C++ and some Ada in the older
systems.
Why don't you use D?
Mike
We're looking into D but at the moment but the general consensus
is that the tooling is not mature enough on ARM (STM32) or Atmel
AVR32 (used in our older devices). Rust is in the same boat.
We have ~250 devs and there are basically three groups, C/C++, D
and Rust. But it pains me to say that all three groups agree that
modern C++ is probably going to win in the end. And I'm broken
after using D, going back to C++ is awful and Rust just has too
much friction to be enjoyable.
bye,
lobo
