Difference between revisions of "Compile-time vs. compile-time"
(stub) |
(expand) |
||
| Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
| − | One of D's oft-touted features is its awesome compile-time capabilities, which open up wonderful meta-programming opportunities, code-generation techniques, compile-time introspection, DSLs that are transformed into code at compile-time and therefore incur zero runtime overhead, and plenty more. | + | One of D's oft-touted features is its awesome compile-time capabilities, which open up wonderful meta-programming opportunities, code-generation techniques, compile-time introspection, DSLs that are transformed into code at compile-time and therefore incur zero runtime overhead, and plenty more. Acronyms like CTFE have become common parlance amongst D circles. |
However, said "compile-time" capabilities are also often the source of much confusion and misunderstanding, especially on the part of newcomers to D, often taking the form of questions posted to the discussion forum by frustrated users, such as: "Why doesn't the compiler let me do ''this''?!", "Why doesn't ''this'' do what I think it should do?", "Why can't the compiler figure this simple thing out?! The compiler is so stupid!", and so on. | However, said "compile-time" capabilities are also often the source of much confusion and misunderstanding, especially on the part of newcomers to D, often taking the form of questions posted to the discussion forum by frustrated users, such as: "Why doesn't the compiler let me do ''this''?!", "Why doesn't ''this'' do what I think it should do?", "Why can't the compiler figure this simple thing out?! The compiler is so stupid!", and so on. | ||
| Line 7: | Line 7: | ||
This article hopes to clear up most of these misunderstandings by explaining just what exactly D's "compile-time" capabilities are, give a brief overview of how it works, and hopefully thereby give newcomers to D a better handle on what exactly can be done, and what to do when you run into a snag. | This article hopes to clear up most of these misunderstandings by explaining just what exactly D's "compile-time" capabilities are, give a brief overview of how it works, and hopefully thereby give newcomers to D a better handle on what exactly can be done, and what to do when you run into a snag. | ||
| − | ==There's compile-time, and there's compile-time== | + | ==There's compile-time, and then there's compile-time== |
| + | |||
| + | Part of the confusion is no thanks to the overloaded term "compile-time". It sounds straightforward enough -- "compile-time" is simply the time when the compiler does whatever it does when it performs its black magic of transforming human-written D code into machine-readable executables. Therefore, if feature X is a "compile-time" feature, and feature Y is another "compile-time" feature, then X and Y ought to be usable in any combination, right? Since, after all, it all happens at "compile-time", so surely the compiler, with its access to black magic, should be able to just sort it all out, no problem. | ||
| + | |||
| + | The reality, of course, is a ''bit'' more involved than this. There are actually, roughly speaking, ''two'' distinct categories of D features that are commonly labelled "compile-time": | ||
| + | |||
| + | * Template expansion, or abstract syntax tree (AST) manipulation; and | ||
| + | * Compile-time function evaluation (CTFE). | ||
Revision as of 19:12, 21 March 2017
Introduction
One of D's oft-touted features is its awesome compile-time capabilities, which open up wonderful meta-programming opportunities, code-generation techniques, compile-time introspection, DSLs that are transformed into code at compile-time and therefore incur zero runtime overhead, and plenty more. Acronyms like CTFE have become common parlance amongst D circles.
However, said "compile-time" capabilities are also often the source of much confusion and misunderstanding, especially on the part of newcomers to D, often taking the form of questions posted to the discussion forum by frustrated users, such as: "Why doesn't the compiler let me do this?!", "Why doesn't this do what I think it should do?", "Why can't the compiler figure this simple thing out?! The compiler is so stupid!", and so on.
This article hopes to clear up most of these misunderstandings by explaining just what exactly D's "compile-time" capabilities are, give a brief overview of how it works, and hopefully thereby give newcomers to D a better handle on what exactly can be done, and what to do when you run into a snag.
There's compile-time, and then there's compile-time
Part of the confusion is no thanks to the overloaded term "compile-time". It sounds straightforward enough -- "compile-time" is simply the time when the compiler does whatever it does when it performs its black magic of transforming human-written D code into machine-readable executables. Therefore, if feature X is a "compile-time" feature, and feature Y is another "compile-time" feature, then X and Y ought to be usable in any combination, right? Since, after all, it all happens at "compile-time", so surely the compiler, with its access to black magic, should be able to just sort it all out, no problem.
The reality, of course, is a bit more involved than this. There are actually, roughly speaking, two distinct categories of D features that are commonly labelled "compile-time":
- Template expansion, or abstract syntax tree (AST) manipulation; and
- Compile-time function evaluation (CTFE).
