Pure dynamic casts?

Steven Schveighoffer schveiguy at yahoo.com
Tue Sep 22 20:39:45 PDT 2009


On Tue, 22 Sep 2009 23:25:26 -0400, Daniel Keep  
<daniel.keep.lists at gmail.com> wrote:

>
>
> Steven Schveighoffer wrote:
>> On Tue, 22 Sep 2009 21:24:10 -0400, Daniel Keep
>> <daniel.keep.lists at gmail.com> wrote:
>>> 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?
>
> What other optimisations?  The only other one I can think of off the top
> of my head is common subexpression elimination.  Except that's
> effectively caller-side memoisation.

Yes, those optimizations :)  They are easy to do and very different than  
parameter memoization because you only optimize where you know it makes a  
difference (and you don't need to use the heap to do it).

>
>>> 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?
>
> I don't know if you've noticed, but objects tend to be allocated on the
> heap, not the stack. :P

The pointer *value* (the actual reference, which is stored on the stack)  
is not being changed.  That's all dynamic cast cares about.  The  
referenced data is irrelevant (except for the classinfo, whose access can  
be factored out of the function, and which isn't possible to change  
without resorting to undefined behavior).

> There's nothing to stop another thread from killing the object you're
> pointing to and then substituting in a new one.  It's pathological, yes,
> but this is the sort of thing that, if it happens, you don't have a hope
> of debugging.  This is why threads completely and utterly suck and I
> frequently wish they'd never been invented.

It's not only pathological, but it's undefined.  We don't care about  
undefined behavior.  A thread can come through and trounce on any memory  
at any time, this is also not a case we need to concern ourselves with.

-Steve



More information about the Digitalmars-d mailing list