Compile time function execution...
Reiner Pope
xxxx at xxx.xxx
Thu Feb 15 22:17:31 PST 2007
Walter Bright wrote:
>> Viewing this as a more complex extension to inlining, I think the
>> correct approach is to allow explicit annotations for 'only at
>> runtime' and 'only at compile time'
>
> I just don't see what is to be gained by this (and consider the extra
> bloat in the language to provide such annotations). The language already
> gives complete, absolute control over when a function is executed.
It's better for the user only to have complete control when desired. The
compiler should infer the rest, but by a better policy than 'leave as
much to runtime as possible', since such a policy misses optimization
opportunities.
Unless I misunderstand, it seems like compile time function execution
opens up a lot of optimization opportunities, yet the programmer is
required to explicitly specify every time they should be used.
From what I understood, this function execution was implemented by
extending const-folding. Wasn't const-folding initially a form of
optimization, to pre-evaluate things, so they didn't need to be
evaluated at runtime?
Consider:
int sq(int val)
{
return val*val;
}
void main()
{
printf( sq(1024) );
}
Although sq() will probably be inlined, if it gets too big, then it
won't. However, there is no reason that it can't be evaluated at
compile-time, which would increase the runtime efficiency. Sure, the
programmer could enforce compile-time evaluation by using
printf( eval!( sq(1024) ) );
but if the compiler can evaluate it automatically, then there would be
no need for programmer annotations here.
I'm just agreeing with Michiel that there should be a compile-time
switch tells the compiler to pre-evaluate as much as possible. This is
an optimization because it means that some code doesn't need to be run
at runtime. I just suggested the 'only at runtime' annotation so that
the programmer has a safeguard against the compiler going wild with
pre-evaluation, for situations like the compressed-code example you
mentioned earlier.
> You can completely ignore and omit the eval!() and your code will run
> just fine. The eval!() is only for those who wish to do some more
> advanced tweaking.
For sure. However, what I referred to in my post was the similarity
between requiring 'inline' in C++ to tell the compiler to optimize the
function call and requiring eval!() in D to tell the compiler to
pre-evaluate the function.
Cheers,
Reiner
More information about the Digitalmars-d
mailing list