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.


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

Jon Skeet - <skeet@xxxxxxxxx> Blog:
If replying to the group, please do not mail me too

Relevant Pages

  • Re: Lock-free reference counting
    ... The scope of t is the entire function foo, ... The reference's lifetime is considerably shorter than ... The only way for it to collect it is if no reference is ... Bindings are introduced by various language constructs. ...
  • Re: VB 6.0 Desktop - Global Variables
    ... variables are not "slower" than local variables. ... wide scope", then this kind of variables only can live in a module. ... standard code module. ... without needing a reference to an object. ...
  • Re: finalize() newbie question
    ... that is not a newbie question at all. ... Although the reference variable "a" has gone out of scope in the ... at the binary level local variables aren't ...
  • Re: Terminology problem
    ... > They don't necessarily share the same scope. ... val exists" is *lifetime*. ... and will cause undefined behavior. ... In fact, since a reference is just another name for an existing object, ...
  • Re: C# equivalent to a smart pointer???
    ... reference locally, that even if the objGlobal reference is set to null, ... The issue is that the lifetime of a local variable is NOT determined by ... within the same scope if it's not used in any code past a certain point. ... in a greater likelihood of incorrect code than the other way would have. ...