Re: Newbie Q: Declare variable IN the loop or BEFORE the loop?



Peter Duniho <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote:
[...]
The problem is that the generated code uses a class <>c__Displayclass2
which has captured *both* "cheap" and "expensive", and longLived has a
reference to an instance of that class.

Ah. I see where my misunderstanding was. I somehow got the impression
that the problem lay in the lifetime of the "shortLived" and "longLived"
variables, when in fact it's the other local variables that they (via the
anonymous delegates) reference that are of concern.

And as you explain, since the problem is that the two variables "cheap"
and "expensive" are tied in lifetime by their being in the same scope, you
get rid of the lifetime problem by moving the "expensive" variable into a
different scope, so that the compiler can generate a new lifetime-managing
class to deal with it separate from "cheap".

Yes - although it's not quite as straightforward as that. If we'd done
the reverse, and put "cheap" into a more nested scope, then that would
have had a reference to the outer scope, and thus "expensive" - we'd
still have the same problem, just in a less immediately direct manner.

[...]
Does that make any kind of sense? (I'm really, really interested in how
best to explain this...)

I believe it does, now. As far as how to better explain it, I am not
sure. However, I can offer the feedback as above, that it's important to
make clear which local variables are affecting how lifetime is managed and
in what way. In the example here, one of the issues is that the lifetime
effects are illustrated through the use of new local variables, making it
hard to distinguish which of the local variables are important in terms of
determining lifetime.

Yup.

Perhaps a better explanation would have had only two local variables, to
ensure that it was clear which variables were important to the definition
of lifetime for each?

Just a thought.

If you mean in Eric's example, I think we would have to have four local
variables, because the problem is when two delegate instances capture
two different variables from the same scope - so you naturally have
four variables.

I think it'll be worth explaining this issue, but some care will be
required...

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.