On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:
Huh? Did I understand right? Just add an empty object.d into
your project and --BetterC is now basically needless, plus the
executable is most likely even smaller?
Kindof, but not exactly. The -betterC switch still adds some
nuance such as...
assert failures are directed to the C runtime library
https://dlang.org/spec/betterc.html
... just to name one.
Though, with 2.079, you should be much less constrained in your
no-/partial- runtime implementation.
For example, I'm exploring a minimal runtime implementation for
using D on bare-metal microcontrollers
(https://github.com/JinShil/stm32f42_discovery_demo) The device
tree (i.e. bus/peripherals/registers/bitfields) is statically
known at compile-time. I use this pattern to model the device
tree...
final abstract class RCC : Peripheral!(AHB1, 0x3800)
{
final abstract class CR : Register!(0x00,
Access.Byte_HalfWord_Word)
{
alias PLLSAIRDY = Bit!(29, Mutability.r);
alias PLLISAION = Bit!(28, Mutability.rw);
}
}
https://github.com/JinShil/stm32f42_discovery_demo/blob/93f2c53578a18e8ce8e6a3985db14f361590f07f/source/stm32f42/rcc.d#L24
That would be impossible with -betterC, because -betterC doesn't
support classes.
I suspect others will find more compelling use cases.
With 2.079 it may also be possible to implement certain features
of D that are disabled in -betterC by providing custom
implementations of runtime hooks
(https://wiki.dlang.org/Runtime_Hooks) or other features in the
runtime.
I'm of the opinion, however, that with the right changes to the
compiler-runtime coupling, as demonstrated in 2.079, a better C
can be achieved without the -betterC compiler switch. There's
still more work to be done, though, and the -betterC compiler
switch will still have its uses. It should be noted, however,
that it was the work done on -betterC that made the changes in
2.079 possible.
Mike
