On 11/11/2015 4:19 AM, Walter Bright 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 ...

I forgot to add:

14. Many C compilers do not emit COMDATs, which cripples flexibility in emitting code.
15. C doesn't give access to special features in the object file, which you may need, such as weak externs, special sections, etc.

On Saturday, 14 November 2015 at 11:30:04 UTC, Walter Bright wrote:
> Like I said, you think the points I raised are all non-issues.

Please don't make assumptions about what I think. What I think is that for a language that is aligned with C semantics, you can with reasonable effort generate good quality C99 code.

> I just have to laugh. You even admit that Microsoft C doesn't implement C99.

That's true. Microsoft has decided that C++ is sufficient. What that means is that you need to target C99 and modern C++.

> I'm sorry, but Modern C does not provide exact representations for 10 bit bytes unless the underlying hardware supports 10 bit bytes. And the 10 bit byte Modern C compilers do not provide representations for 8 bit bytes.

That is true, but that is a very unlikely target today, and neither D or Rust support this configuration AFAIK. Even 24 bit integers are rare, though they exists in some DSP CPUs.

On Saturday, 14 November 2015 at 11:30:04 UTC, Walter Bright wrote:
> Guess what happened when I found out that people were relying on bugs in gcc's preprocessor, not to mention all of its non-standard behavior.

Off-topic, but I'd like to know more about that. Did you by any chance ever wrote a blog post of some sort describing thoses issues?

On 11/14/2015 4:35 AM, cym13 wrote:
> Off-topic, but I'd like to know more about that. Did you by any chance ever
> wrote a blog post of some sort describing thoses issues?


Sorry, it was a couple years ago, I don't recall the specifics.

On 11/14/2015 3:39 AM, Ola Fosheim Grøstad wrote:
> What I think is that for a
> language that is aligned with C semantics, you can with reasonable effort
> generate good quality C99 code.

https://www.youtube.com/watch?v=YlVDGmjz7eM

:-)

On Saturday, 14 November 2015 at 16:19:13 UTC, Walter Bright wrote:
> On 11/14/2015 3:39 AM, Ola Fosheim Grøstad wrote:
>> What I think is that for a
>> language that is aligned with C semantics, you can with reasonable effort
>> generate good quality C99 code.
>
> https://www.youtube.com/watch?v=YlVDGmjz7eM
>
> :-)

https://www.youtube.com/watch?v=CfdFw3hXkf0

On 2015-11-14 07:31, Sergey Korshunoff via Digitalmars-d wrote:

> PS: you just say that C is not suitable for the system programming

Well, he is the creator of D ;)

-- 
/Jacob Carlborg