Pure dynamic casts?

[Steven Schveighoffer]

On Tue, 22 Sep 2009 21:24:10 -0400, Daniel Keep  
<daniel.keep.lists at gmail.com> wrote:

>
>
> Steven Schveighoffer wrote:
>> On Tue, 22 Sep 2009 05:24:11 -0400, Daniel Keep
>> <daniel.keep.lists at 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