On Tue, 22 Sep 2009 21:24:10 -0400, Daniel Keep
<daniel.keep.li...@gmail.com> wrote:
Steven Schveighoffer wrote:
On Tue, 22 Sep 2009 05:24:11 -0400, Daniel Keep
<daniel.keep.li...@gmail.com> wrote:
Jason House wrote:
Dynamic casts are pure. They don't use global state, and have the
same output for the same reference as input. Interestingly, dynamic
cast results are independent of intervening mutable calls... So
there's even greater opportunity for optimization.
What if the GC just happens to re-use that address for a different
object?
That's only if memoization is used.
Well, if you're not looking at memoization, why is this discussion even
happening?
There are other pure optimizations that can occur without memoization. In
fact I don't even know why memoization is brought up so much with pure
functions, it is an impossible-to-prove optimization. How do you know
memoization helps when you don't know how often the same arguments will be
used?
I think what Jason said is correct -- you can view dynamic cast as
taking 2 arguments, one is the reference which is simply echoed as the
return value, and one is the classinfo, which is an immutable argument
that causes a decision to be made.
The reference *isn't* echoed as a return value. If it was, then casting
wouldn't do anything.
Well, either the reference itself, an offset reference, or null is
returned. Sorry I wasn't explicit.
In fact, you could use memoization on a dynamic cast subfunction that
memoizes on the target type and the classinfo of the source, regardless
of the reference value, and returns an offset to add to the return
value.
Yes, that would work, provided both references are immutable.
The classinfo is immutable, it's always the same. Why does the data
reference have to be immutable? It's not even dereferenced. Think of it
as an integer.
It's pretty easy for the compiler to prove that o has not be reassigned,
so even without memoization, the compiler can logically assume that the
result from the first dynamic cast can be reused. I think this is the
major optimization for pure functions anyways, not memoization.
Pretty easy? So you're ignoring threads, then?
The ONLY way I can see object casting being treated as a pure function
is if all references passed in are immutable and even then only if the
compiler can prove the reference cannot be changed (i.e. the reference
is always kept on the stack AND you assume you never manually delete it).
How is a thread going to come along and change a local variable in another
thread?
-Steve
-- Daniel
--- Steve
