On 4 January 2012 16:28, Andrei Alexandrescu <[email protected]>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.
