Steven Schveighoffer wrote:
On Fri, 09 Oct 2009 09:27:01 -0400, Don <[email protected]> wrote:
Steven Schveighoffer wrote:
On Fri, 09 Oct 2009 08:34:31 -0400, Don <[email protected]> wrote:
I don't understand why runtime-determined array literals even exist.
They're not literals!!!
They cause no end of trouble. IMHO we'd be *much* better off without
them.
I don't agree. Here is a runtime decided array literal:
void foo(int a, int b, int c)
{
auto x = [a, b, c];
}
The alternatives are:
// template function
auto x = createArray(a, b, c);
// mixin?
Although the template function looks nice, it adds bloat.
There's no bloat. You just need a type-safe variadic.
T[] createArray(T)(T[] args...);
One function per type. That's the best you're ever going to do with
run-time construction anyway.
Actually, there's horrific bloat present right now. Look at the code
generated when you use an array literal.
If you have a function that takes a typesafe variadic array, what is the
compiler going to do to pass that data into the function? Push it on
the stack, call a function, and then the function is going to do the
same thing a literal would do, reading the data off the stack? How is
that not worse than an array literal generating code to build an array?
That's exactly what the compiler does right now. It pushes all the
values onto the stack, then calls a function to create a literal <g>.
> Not to mention the added symbol bloat.
That's the only kind of bloat the template solution could give you.
Generated code isn't bloat if it's the minimal work that has to be done
to get what you want.
Yes, but at present it always generating code for the worst case.
On top of that, what if a, b, and c are runtime decide, then during
development, or with a new compiler, they can now be CTFE decided?
Now you are calling some function when they *could* be in a literal.
This is exactly the problem.
They should ALWAYS require CTFE evaluation.
EG:
immutable(double)[] tableOfSines = [ sin(0.0), sin(PI/4), sin(PI/2),
sin(3*PI/4), sin(1)];
Obviously, these values should be be compile-time evaluated. But how
does the compiler know that? It can't.
Right now, this is done at run-time.
I'm not extremely well-versed in what triggers CTFE, but it seems
logical to me that the compiler can determine that it can be evaluated
at compile-time, assuming sin is marked as pure (or maybe even if it
isn't). What am I missing?
A function can be pure even if it does a huge calculation that takes
days. CTFE is only triggered if used in a situation where a compile-time
constant is _mandatory_. You have to explicitly ask for CTFE somehow.
Runtime array creation is a prime candidate for moving from language
to libraries.
It is a solution, but I think the better solution is you just write what
you want and the compiler figures out the best move. Whether it's heap
allocated or not, created at runtime or not, is an implementation detail
I don't think the user needs to worry about.
I think it's really misleading to have an expensive operation
masqueriding as a free one. Suppose you have a 20000 element array
literal, all constants, and then you change one element to 'x+2' where x
is a local variable. Suddenly, instead of just getting a pointer to
statically-loaded data, you're pushing 20000 things onto the stack!
Creating an array at run-time seems to be a kind of constructor call to
me. Using array literal syntax for runtime initialization gives the same
problems Andrei discussed in the 'new' thread. Eg, it's not polymorphic.
I suspect that uses of run-time array literals are really rare. My code
is full of compile-time array literals, but I've never seen a run-time
usage.
