Shouldn't invalid references like this fail at compile time?

[lobo]

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