Simple names are not so simple, Part Two, plus, volcanoes and fried foods

re: Simple names are not so simple, Part Two, plus, volcanoes and fried foods

Sanil — Sat, 14 Nov 2009 19:59:13 GMT

Hi Eric!

Just a humble request, can you read my post http://www.thewiredguy.com/wordpress/?p=62

and validate my approach (and point out any pitfalls) to LINQ problem you mentioned in your previous blog post :)

re: Simple names are not so simple, Part Two, plus, volcanoes and fried foods

configurator — Fri, 13 Nov 2009 04:44:10 GMT

"No, and no. -- Eric"

I think the story would be even more interesting if a manager suddenly popped out from behind a bush and gave her the fish.

By the way, are all Maui names as short as your friends'? That would be quite confusing whenever in a group of about eight or more people.

re: Simple names are not so simple, Part Two, plus, volcanoes and fried foods

Mark — Sun, 08 Nov 2009 01:19:04 GMT

Gabe: Mahalo

re: Simple names are not so simple, Part Two, plus, volcanoes and fried foods

mike — Fri, 06 Nov 2009 16:28:23 GMT

I find it kind of amazing that you have such in-depth knowledge about Hannah Montana and her alter ego. I didn't know that, and we have a subteen female child in the house.

I don't. I looked it up on wikipedia. -- Eric

re: Simple names are not so simple, Part Two, plus, volcanoes and fried foods

Niall Connaughton — Fri, 06 Nov 2009 15:01:27 GMT

In regards to your first comment on configurator's post, it always felt to me that having the loop variable for a foreach declared in the outer declaration space leads to unintuitive behaviour of closures inside the foreach. ie: it felt intuitive to me to have a fresh new delegate for each loop, with a fresh new "m" as you say.

Does the current behaviour exist due to the C# specification mandating it be so before closures existed in C#? Or is this desired behaviour and I'm missing some understanding of why declaring the variable in the outer scope is better?

The former. It is undesirable behaviour and we are considering taking the breaking change. I've been meaning to blog about this for a while. -- Eric

re: Simple names are not so simple, Part Two, plus, volcanoes and fried foods

AnnoyedFromMidwest — Fri, 06 Nov 2009 11:05:52 GMT

Did the manager turn up and did the customer get the fish without the chips?

No, and no. -- Eric

re: Simple names are not so simple, Part Two, plus, volcanoes and fried foods

Gabe — Fri, 06 Nov 2009 06:45:53 GMT

Thank you for spelling the okina (the glottal stop in Hawaiian words) as an ANSI-standard apostrophe rather than some obscure Unicode character that only exists in exotic Unicode fonts.

That wasn't deliberate; I had no idea it was anything other than an apostrophe. -- Eric

re: Simple names are not so simple, Part Two, plus, volcanoes and fried foods

configurator — Thu, 05 Nov 2009 22:25:44 GMT

Two quick questions.

1. Is the code

int m;
while(e.MoveNext()) {
m = e.Current;
Console.Write(m);
}

And the code

while (e.MoveNext()) {
int m = e.Current;
Console.Write(m);
}

Equivalent, or is there any difference, besides having the variable unnecessarily in the outer declaration space?

Those are equivalent, but if instead of Console.Write(m), that was M(()=>m), then there would be a difference. The first program would call M with the same delegate over and over, a delegate closed over the single outer variable m. The second program would call M with a fresh new delegate each time, each one bound to a fresh new "m". -- Eric

is the variable in the second example reallocated in each iteration, or does the CLR know to do the "smart thing" and allocate it only once?

In the straightforward non-closure case, the jitter generates code which re-uses the same stack slot or register in both scenarios. In the closure case, things get much more complicated because we must allocate closure classes; since the variables can survive beyond the loop body if the delegate survives, then the storage cannot be re-used in the second case. -- Eric

2. Why m = (int)(int)e.Current(); and not m = e.Current; ?

I was being uber-picky. The spec states that the code generation for a foreach loop is to determine the loop variable type V, and the type of the collection elements, T, and then do casts (V)(T)e.Current; The cast to T is actually redundant, though the cast to V is a true cast that can produce failures. -- Eric

re: Simple names are not so simple, Part Two, plus, volcanoes and fried foods

Rob — Thu, 05 Nov 2009 19:53:13 GMT

It physically pains me to be pointing this out, but it's Miley Cyrus, not Stewart.

OW.

I hate to be contradictory, but no, it is in fact Miley Stewart who is the secret identity of Hannah Montana. Miley Stewart/Hannah Montana are played by an actress named Miley Cyrus. OW OW OW. -- Eric