D as a Better C

[Michael V. Franklin via Digitalmars-d-announce]

On Thursday, 24 August 2017 at 18:26:37 UTC, H. S. Teoh wrote:

>> For instance, a D project targeting STM board, makes heavy use 
>> of classes and templates, resultant code segment is 3k.
>> 
>> https://github.com/JinShil/stm32f42_discovery_demo#the-good

> To be fair, though, the above-mentioned project did have to 
> create a stub druntime in order to get things to work.  Not 
> everyone may have the know-how required to construct a minimal 
> druntime that works for their purposes.

Those runtime stubs are needed precisely because of problems in 
D's implementation.  If the implementation were fixed, none of 
those stubs would be required, and neither would the -betterC 
switch.

Because the project above is not using any feature provided by 
those runtime stubs, those stubs should not be required, and 
neither should the -betterC switch.

GDC has made some improvements here, and that is why the project 
above only compiles with GDC.

LDC doesn't even display an error message when those stubs aren't 
created.  Instead it enters a codegen loop generating a 
gargantuan multi-gigabyte file, ultimately crashing my VM 
(https://github.com/ldc-developers/ldc/issues/781).

Sometimes, however, it is not known whether a runtime feature 
will be needed until link-time.  In that case, it's OK for the 
compiler to emit TypeInfo, ModuleInfo, etc..., but it should do 
so in a way that the linker (with either LTO or --gc-sections) 
can determine what is needed and what isn't and discard that 
which isn't needed.  Once unneeded object code is discarded, the 
linker errors disappear, and you get a functioning executable 
without linking in the runtime and without a -betterC switch.

GDC recently implemented such an improvement 
(https://github.com/D-Programming-GDC/GDC/pull/505).  It brought 
my binary size from 600kB to 6KB, so now I can get back to 
microcontroller programming in D.  This is the kind of work 
that's needed.

Mike