System programming in D (Was: The God Language)

[Manu]

On 4 January 2012 16:28, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

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


It's rare to step through optimised code. You tend to debug and step in
debug/unoptimised builds, where inline functions are usually not even
inlined, and code flow still looks natural, and easy to follow.. This saves
lots of time.
C/C++ macros present the same problem of not being able to step and inspect
values. Most industry programmers I work with tend to avoid macros for this
reason above all others.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120105/69d644fc/attachment.html>