On Wednesday, 11 November 2015 at 12:19:40 UTC, Walter Bright
wrote:
On 11/9/2015 3:26 PM, deadalnix wrote:
I've looked into generating C code as an output format. I found
the problems to be endemic and working around them was harder
than just generating native code:
1. You're at the mercy of bugs in the C compiler you cannot fix.
2. C leaves quite a lot as "implementation defined", causing
endless compatibility issues with various C compilers.
3. C's integral promotion rules.
4. Generating exception handling code for C is miserable and
inefficient.
5. Your compiler is going to be slower than C.
6. You'll suffer from endless bug reports caused by a mismatch
between your compiler and the user's C compiler, whatever that
might be.
7. You cannot generate symbolic debug info in a format that
looks like your language's definitions.
8. C's symbols will differ from your program's symbols, again
making use of a debugger about like debugging code with an asm
debugger, only much worse.
9. The generated C code will look awful.
10. The order of evaluation of C code expressions is
implementation defined.
11. Installation problems, again, because you don't control the
user's C compiler.
12. If your language supports a basic type that isn't supported
by C, tough noogies (think SIMD types).
13. C has no concept of immutability or purity, so no hope of
getting the C optimizer to take advantage of that.
... and on ...
Nice list. I was always wondering, if it made sense to generate C.
So D does a better job at interfacing to C/C++, because it uses
the same memory model as C/C++, as opposed to outputting C code
like Nim. This is actually very clever.
