Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Given that C has raw pointers and inline assembly, what is D doing that it couldn't (easily?) express?


1. cannot support anything but the C ABI

2. cannot support exception handling

3. cannot support types that C doesn't

4. stuck with C symbolic debug info, not your language's

5. cannot innovate with things like how strings are stored

6. many C compilers do not emit COMDATs

7. no thread local storage

8. chained to slow compilation speeds

9. stuck with trying to find a way to work around C compiler bugs

10. stuck with whatever C compiler the user has, i.e. one has to support multiple versions of multiple C compilers

11. C compiler can change, breaking your compiler

The original C++ compiler, cfront, had a LOT of problems with these issues.


Thanks for taking the time to respond, compilers are always interesting to learn about!

Point 7 was (finally!) addressed by C11.

Points 6, 8, 9, 10, & 11 are all good ones that hadn't occurred to me.

It seems like points 1, 4, & 5 could be worked around, but I can see where the added complexity would be unwelcome.

On the whole, I can see why you made the decision you did. However, I don't buy points 2 (exception handling) and 3 (type support). Certainly C doesn't have these things built in, but appropriate code transformations seem to suffice in practice. For example, the CHICKEN Scheme to C compiler employs continuation-passing style [1] and Embeddable Common Lisp [2] manages to compile to C without (to my knowledge) breaking either its type system or its condition and restart [3] system.

[1] https://wiki.call-cc.org/chicken-compilation-process

[2] https://www.cliki.net/ECL

[3] http://www.gigamonkeys.com/book/beyond-exception-handling-co...


2. yes, it can be done with setjmp/longjmp, but that's a terrible solution

3. if the C compiler doesn't support 80 bit reals (and D does), you're out of luck.

I looked at the C code generated by C++ cfront. No thanks.

The worst is, the C compiler vendor owns you, and they couldn't care less about you.


Inline assembly is a compiler extension and not portable.

Beyond that, sure you can do whatever you want in C if you're willing to mess with assembly and non-portable memory tricks but at this point you're better off writing your own native backend. The whole point of generating C instead of machine code is to leverage the existing compiler infrastructure to support a vast number of architectures and generate efficient code. If you just dump inline assembly in a C function or rely on opaque memory shenanigans the C compiler won't be able to meaningfully optimize your code and it probably won't be portable.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: