System programming in D (Was: The God Language)

[Andrei Alexandrescu]

On 1/4/12 3:39 AM, Manu wrote:
>   * __forceinline ... I wasn't aware this didn't exist... and yes,
> despite all this discussion, I still depend on this all the time. People
> are talking about implementing forceinline by immitating macros using
> mixins.... crazy? Here's a solid reason I avoid mixins or procedurally
> generated code (and the preprocessor in C for that matter, in favour of
> __forceinline): YOU CAN DEBUG IT. In an inline function, the code exists
> in the source file, just like any other function, you can STEP THE
> DEBUGGER through it, and inspect the values easily. This is an
> underrated requirement. I would waste hours on many days if I couldn't
> do this. I would only ever use string mixins for the most obscure uses,
> preferring inline functions for the sake of debugging 99% of the time.

Hmmm, I see that the other way around. D CTFE-generated macros are much 
easier to debug because you can actually print the code before mixing it 
in. If it looks like valid code... great.

I think the deal with inline functions is significantly more complex. 
Inlining is the first step in a long pipeline of optimizations that 
often make the code virtually unrecognizable and impossible to map back 
to source in a way that's remotely understandable.


Andrei