Specializing on Compile Time Constants
Lars T. Kyllingstad
public at kyllingen.NOSPAMnet
Tue Oct 13 00:11:08 PDT 2009
dsimcha wrote:
> == Quote from Jacob Carlborg (doob at me.com)'s article
>> On 10/12/09 23:49, dsimcha wrote:
>>> I'm working on a mathematical expression interpreter for D, which would allow
>>> for closed form mathematical expressions to be specified as string literals at
>>> runtime and be evaluated. For example:
>>>
>>> MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
>>> writeln(myExpression(2)); // Does exactly what you think it does.
>>>
>>> I've found the syntax so convenient that I'd like to transparently specialize
>>> it on strings known at compile time. The idea is that, when the expression is
>>> hard-coded, you will still be able to use the MathExp interface, but your
>>> expression will evaluate at the full speed of a statically compiled function.
>>> Is there any way to test whether the value of an argument to a template
>>> function is known at compile time and specialize on this?
>> Doesn't all values to a template have to be known at compile time
>
> No, I mean the *function* parameters of a template function.
I may be wrong, but I seem to remember reading somewhere that DMD always
tries to evaluate as much as possible at compile time. That is, if a
function is CTFE-enabled, and its input is known at compile time, it is
calculated at compile time.
void main(string[] args) {
auto x = foo(args[1]); // foo() is evaluated at run time
auto y = bar("baz"); // foo() is evaluated at compile time
}
That said, I also seem to remember that the use of structs and classes
is very limited (or nonexistent) in CTFE, and I guess your mathExp() is
supposed to return a MathExp struct...
-Lars
More information about the Digitalmars-d
mailing list