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

[Peter Duniho]

[...]
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".

[...]
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.

Pete

 

[Jon Skeet [C# MVP]]

[...]
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...

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

So you were taught to Dim all your variables at the top of the
procedure.. Its what VB6 does anyway.. it dims everything at procedure
start whether it will be used or not. Lame language.

Actually, every language that I know of does this. It's not lame, it's
efficient.

When calling a method, a stack frame is created with the size of all
local variables that is used in the method.

The difference with VB, though, is that the variables are automatically
initialised, while in C# they are undefined.

 

[Peter Duniho]

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.

But the delegate instances could have been stored anywhere, right? They
don't need to be local variables.

I'm not saying there don't need to be four variables *somewhere*, just
that putting them all together makes it confusing as to which are the ones
affected directly by the scope.

Maybe I'm off-course here, but when I read the example in Eric's post that
you referenced, it occurs to me that if those delegates had, for example,
gotten handed off to an event or a thread or something like that, the
captured variables lifetime becomes even more significant. And doing so
would avoid having them referenced directly by locals in the method where
the others are scoped.

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

No doubt.

Pete

 

[Jon Skeet [C# MVP]]

But the delegate instances could have been stored anywhere, right? They
don't need to be local variables.

Yes, that's true.

I'm not saying there don't need to be four variables *somewhere*, just
that putting them all together makes it confusing as to which are the ones
affected directly by the scope.

Right. I'll remember that

Maybe I'm off-course here, but when I read the example in Eric's post that
you referenced, it occurs to me that if those delegates had, for example,
gotten handed off to an event or a thread or something like that, the
captured variables lifetime becomes even more significant. And doing so
would avoid having them referenced directly by locals in the method where
the others are scoped.

Indeed. The anonymous method itself has to still be in the method, of
course, but that's a different matter.

No doubt.

It's amazing how many things are easy to explain until you need to be
really careful. I've never needed to know about open/closed/constructed
types in reality, but talking about generics kinda requires it - and
it's a pain!