Nick Sabalausky wrote: > "Adam D. Ruppe" <[email protected]> wrote in message > news:[email protected]... >> Marco Leise wrote: >>> An unlikely example would be a C compiler within CTFE that takes a >>> string of C source code and turns it into a D mixin. Is that >>> possible? >> >> It'd be a fair amount of work, but it should be possible. >> >> It's tempting to try to implement that as an alternative to D >> bindings modules. >> >> mixin include_C ( import("stdio.h") ); >> > > It's a neat possibility, but the downside of that approach, I suspect, is > that it may slow down compilation. > > With that approach, "stdio.h" has to be processed *every* time your program > is compiled, not just whenever "stdio.h" is changed (which is what you would > get if the conversion were done with a separate tool and a proper > buildsystem). Also, I'm sure that CTFE is probably slower than running an > already compiled tool. It would have to be slower, since it *is* > interpreted, after all. > This is another reason why CTFE really needs to support IO access (I really > believe the strict adherance to "CTFE must be *guaranteed* stateless" is a > mistake. It's right to strongly discourage it, but making the ban this > strict is taking things too far - similar to Java's ban on pointers). Then, > include_C could be implemented roughly like this: > [snip.]
Another interesting way to speed up CTFE-heavy code compilation in a incremental build environment would be to allow the compiler to cache the internal AST-representation of the code after semantic analysis, in some kind of temporary file.
