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

... 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);

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.


Reply via email to