Steven Schveighoffer wrote:
> On Tue, 22 Sep 2009 21:24:10 -0400, Daniel Keep
> <daniel.keep.li...@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.
>> 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
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 also incidentally why I've personally come to regard reference
semantics, in general, as a really, REALLY stupid idea.
>>
>>> -Steve
>>
>> -- Daniel
>
> --- Steve
--------- Daniel
