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