Discussion:
Funny loop with post-increment.
Brady Kelly
2008-02-19 07:37:59 UTC
Permalink
Why does this loop not exit? On the first iteration, one would expect i ==
0, and that 0 to be assigned to i, and then i incremented. Then, on the
second iteration, i should be 1 before the assignment operation, as well as
after the assignment operation, but i should be two after the
post-increment, before the next assignment.



int i = 0;

while (i < 10)

{

i = i++;

}


===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Per Bolmstedt
2008-02-19 07:51:51 UTC
Permalink
Post by Brady Kelly
int i = 0;
while (i < 10)
{
i = i++;
}
Why does this loop not exit? On the first iteration, one would expect i ==
0, and that 0 to be assigned to i, and then i incremented. Then, on the
Depending on which "i" you are talking about, that's either true or false. =]

Maybe if you break it up into smaller operations and step through the code,
it would be more clear. Assign the result of i++ to a temporary variable
before you assign it back to i, etc.

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 08:05:40 UTC
Permalink
Post by Brady Kelly
Why does this loop not exit? On the first iteration, one would expect i ==
0, and that 0 to be assigned to i, and then i incremented. Then, on the
second iteration, i should be 1 before the assignment operation, as well as
after the assignment operation, but i should be two after the
post-increment, before the next assignment.
int i = 0;
while (i < 10)
{
i = i++;
}
i=i++ is effectively this:

int tmp = i;
i = i + 1;
tmp = i;

In other words, the increment happens after the evaluation of i, but
before the assignment - so the assignment just sets it back to the
original value.

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Frans Bouma
2008-02-19 08:14:50 UTC
Permalink
Post by Jon Skeet
Post by Brady Kelly
Why does this loop not exit? On the first iteration, one would expect i ==
0, and that 0 to be assigned to i, and then i incremented. Then, on the
second iteration, i should be 1 before the assignment operation, as well as
after the assignment operation, but i should be two after the
post-increment, before the next assignment.
int i = 0;
while (i < 10)
{
i = i++;
}
int tmp = i;
i = i + 1;
tmp = i;
In other words, the increment happens after the evaluation of i, but
before the assignment - so the assignment just sets it back to the
original value.
I don't find this obvious. Right-hand side of the assignment should be
evaluated first, so:
i=i+1
i=i

I don't see how /why a temp variable is suddenly created.

FB

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 08:24:04 UTC
Permalink
Post by Frans Bouma
Post by Jon Skeet
In other words, the increment happens after the evaluation of i, but
before the assignment - so the assignment just sets it back to the
original value.
I don't find this obvious. Right-hand side of the assignment should be
i=i+1
i=i
The RHS of the assignment *is* evaluated first - the result of "i++" is
the value *before* the increment. So, when i = 0 the value of the
expression "i++" is 0. That value is then assigned to i.
Post by Frans Bouma
I don't see how /why a temp variable is suddenly created.
From the spec (7.5.9)

<quote>
• If x is classified as a variable:
o x is evaluated to produce the variable.
o The value of x is saved.
o The selected operator is invoked with the saved value of x as its
argument.
o The value returned by the operator is stored in the location given by
the evaluation of x.
o The saved value of x becomes the result of the operation.
</quote>

Here I'm just using tmp to be "the saved value".


Jon

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Ryan Heath
2008-02-19 08:35:38 UTC
Permalink
For one reason I had always thought C# had abandoned this peculiar C++
feature...

Anyone know why C# has this feature, its obvious that still people are
confused of it.
Wasn't C# about getting things *simpler and easier* than its cousins C/C++ ?

// Ryan
Post by Jon Skeet
Post by Frans Bouma
Post by Jon Skeet
In other words, the increment happens after the evaluation of i, but
before the assignment - so the assignment just sets it back to the
original value.
I don't find this obvious. Right-hand side of the assignment should be
i=i+1
i=i
The RHS of the assignment *is* evaluated first - the result of "i++" is
the value *before* the increment. So, when i = 0 the value of the
expression "i++" is 0. That value is then assigned to i.
Post by Frans Bouma
I don't see how /why a temp variable is suddenly created.
From the spec (7.5.9)
<quote>
o x is evaluated to produce the variable.
o The value of x is saved.
o The selected operator is invoked with the saved value of x as its
argument.
o The value returned by the operator is stored in the location given by
the evaluation of x.
o The saved value of x becomes the result of the operation.
</quote>
Here I'm just using tmp to be "the saved value".
Jon
===================================
This list is hosted by DevelopMentor(R) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Shawn Wildermuth
2008-02-19 08:39:04 UTC
Permalink
Because:

for (int x = 0; x < 10; ++x) {}

Is sooooo pretty?

Thanks,

Shawn Wildermuth
http://adoguy.com
http://wildermuthconsulting.com
Microsoft MVP (C#), MCSD.NET, Author and Speaker

The Silverlight Tour is coming to a city near you!


-----Original Message-----
From: Discussion of development on the .NET platform using any managed
language [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Ryan Heath
Sent: Tuesday, February 19, 2008 3:36 AM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-CLR] Funny loop with post-increment.

For one reason I had always thought C# had abandoned this peculiar C++
feature...

Anyone know why C# has this feature, its obvious that still people are
confused of it.
Wasn't C# about getting things *simpler and easier* than its cousins C/C++ ?

// Ryan
Post by Jon Skeet
Post by Frans Bouma
Post by Jon Skeet
In other words, the increment happens after the evaluation of i, but
before the assignment - so the assignment just sets it back to the
original value.
I don't find this obvious. Right-hand side of the assignment should be
i=i+1
i=i
The RHS of the assignment *is* evaluated first - the result of "i++" is
the value *before* the increment. So, when i = 0 the value of the
expression "i++" is 0. That value is then assigned to i.
Post by Frans Bouma
I don't see how /why a temp variable is suddenly created.
From the spec (7.5.9)
<quote>
o x is evaluated to produce the variable.
o The value of x is saved.
o The selected operator is invoked with the saved value of x as its
argument.
o The value returned by the operator is stored in the location given by
the evaluation of x.
o The saved value of x becomes the result of the operation.
</quote>
Here I'm just using tmp to be "the saved value".
Jon
===================================
This list is hosted by DevelopMentor(R) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentorR http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 08:39:17 UTC
Permalink
Post by Ryan Heath
For one reason I had always thought C# had abandoned this peculiar C++
feature...
Which feature exactly?
Post by Ryan Heath
Anyone know why C# has this feature, its obvious that still people are
confused of it.
Wasn't C# about getting things *simpler and easier* than its cousins C/C++ ?
And it is - I believe the result is undefined in C++. C# clearly defines
what the result should be.

Now code like this should be avoided, certainly - but try prohibiting it
within the language spec! (The spec would be very, very tricky to get
right - and it might not even be possible.)

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Ryan Heath
2008-02-19 08:48:04 UTC
Permalink
Post by Jon Skeet
Which feature exactly?
The feature that the returned value of i++ is i and not i+1.
Post by Jon Skeet
Now code like this should be avoided, certainly - but try prohibiting it
within the language spec! (The spec would be very, very tricky to get
right - and it might not even be possible.)
Why is it not simply the obvious value? That could have been documented.

Btw. Is the returned value of ++i, i or i+1?

// Ryan

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 08:53:04 UTC
Permalink
Post by Ryan Heath
Post by Jon Skeet
Which feature exactly?
The feature that the returned value of i++ is i and not i+1.
Um, that's the definition of post-increment. If you want pre-increment,
use ++i. Sometimes you want post-increment behaviour, sometimes you want
pre-increment behaviour - but you need to know what they both do.
Post by Ryan Heath
Post by Jon Skeet
Now code like this should be avoided, certainly - but try prohibiting it
within the language spec! (The spec would be very, very tricky to get
right - and it might not even be possible.)
Why is it not simply the obvious value? That could have been documented.
It *is* documented. Everything is working exactly as specified, and I
don't see anything wrong with how it's specified.
Post by Ryan Heath
Btw. Is the returned value of ++i, i or i+1?
The value of i after the increment.

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Brady Kelly
2008-02-19 09:01:09 UTC
Permalink
Post by Ryan Heath
The feature that the returned value of i++ is i and not i+1.
I've always accepted that as a given, it's just in this situation I thought
i would be assigned i, not i+1, then i would be incremented, not i
incremented and pre-i++ assigned back to i.

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
silky
2008-02-19 09:08:21 UTC
Permalink
Post by Brady Kelly
Post by Ryan Heath
The feature that the returned value of i++ is i and not i+1.
I've always accepted that as a given, it's just in this situation I thought
i would be assigned i, not i+1, then i would be incremented, not i
incremented and pre-i++ assigned back to i.
it's not "pre" i++. it happens after that. i is equal to the result of
the expression "i++". what you are missing is that i++ in that
expression doesn't actually affect the end result of "i" (even though
it is calculated) because it's overwritten.

--
http://lets.coozi.com.au/

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Brady Kelly
2008-02-19 09:13:59 UTC
Permalink
Post by silky
it's not "pre" i++. it happens after that. i is equal to the result of
the expression "i++". what you are missing is that i++ in that
expression doesn't actually affect the end result of "i" (even though
it is calculated) because it's overwritten.
I'm not missing anything any more, thank you everyone, but I figured it out
Post by silky
i is 0
<begin i++>
tmp = i
i += 1
<end i++>
i = tmp
===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Chris Tavares
2008-02-19 08:27:24 UTC
Permalink
Don't forget that this is a POST-increment. The return value of i++ is the
original value of i, before it was incremented.

-Chris

-----Original Message-----
From: Discussion of development on the .NET platform using any managed
language [mailto:DOTNET-***@DISCUSS.DEVELOP.COM] On Behalf Of Frans Bouma
Sent: Tuesday, February 19, 2008 12:15 AM
To: DOTNET-***@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-CLR] Funny loop with post-increment.
Post by Jon Skeet
Post by Brady Kelly
Why does this loop not exit? On the first iteration, one would expect i ==
0, and that 0 to be assigned to i, and then i incremented. Then, on the
second iteration, i should be 1 before the assignment operation, as well as
after the assignment operation, but i should be two after the
post-increment, before the next assignment.
int i = 0;
while (i < 10)
{
i = i++;
}
int tmp = i;
i = i + 1;
tmp = i;
In other words, the increment happens after the evaluation of i, but
before the assignment - so the assignment just sets it back to the
original value.
I don't find this obvious. Right-hand side of the assignment should
be
evaluated first, so:
i=i+1
i=i

I don't see how /why a temp variable is suddenly created.

FB

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Brady Kelly
2008-02-19 08:33:21 UTC
Permalink
Post by Chris Tavares
Don't forget that this is a POST-increment. The return value of i++ is the
original value of i, before it was incremented.
-Chris
I think we all know how post-increment works. The question was why was i
_still_ zero on the second loop iteration, after it should have been
post-incremented.

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 08:37:51 UTC
Permalink
Post by Brady Kelly
Post by Chris Tavares
Don't forget that this is a POST-increment. The return value of i++ is the
original value of i, before it was incremented.
I think we all know how post-increment works. The question was why was i
_still_ zero on the second loop iteration, after it should have been
post-incremented.
If you knew how post-increment worked, why would there be a question?

The important thing to know is that the post-increment happens before
post expression evaluation, rather than post statement execution. To me,
that's part of knowing how post-increment works.

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
silky
2008-02-19 08:44:20 UTC
Permalink
Post by Brady Kelly
Post by Chris Tavares
Don't forget that this is a POST-increment. The return value of i++ is the
original value of i, before it was incremented.
-Chris
I think we all know how post-increment works. The question was why was i
_still_ zero on the second loop iteration, after it should have been
post-incremented.
it doesn't matter how many iterations; the value of anything that is
assigned as a postincrement (a = n++) is always equal to n. so that's
how it's defined in the spec and this is a side-effect of that
implementation. the thing to note is that the n++ is resolved directly
after that, before the statement itself has completed (i.e. the
function f(n++, n) results in differing values for the two params).

it's a specific result of the definition of the post-increment operation.

--
http://lets.coozi.com.au/

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Frans Bouma
2008-02-19 08:44:18 UTC
Permalink
Post by Chris Tavares
Don't forget that this is a POST-increment. The return value of i++ is the
original value of i, before it was incremented.
ooohh! Of course!

Then it makes sense. (but the compiler should throw a warning, as it's
non-obvious code. For the 99% of the C# users who don't know the spec in every
detail)

FB
Post by Chris Tavares
-Chris
-----Original Message-----
From: Discussion of development on the .NET platform using any managed
Sent: Tuesday, February 19, 2008 12:15 AM
Subject: Re: [DOTNET-CLR] Funny loop with post-increment.
Post by Jon Skeet
Post by Brady Kelly
Why does this loop not exit? On the first iteration, one would expect i
==
Post by Jon Skeet
Post by Brady Kelly
0, and that 0 to be assigned to i, and then i incremented. Then, on the
second iteration, i should be 1 before the assignment operation, as well
as
Post by Jon Skeet
Post by Brady Kelly
after the assignment operation, but i should be two after the
post-increment, before the next assignment.
int i = 0;
while (i < 10)
{
i = i++;
}
int tmp = i;
i = i + 1;
tmp = i;
In other words, the increment happens after the evaluation of i, but
before the assignment - so the assignment just sets it back to the
original value.
I don't find this obvious. Right-hand side of the assignment should be
i=i+1
i=i
I don't see how /why a temp variable is suddenly created.
FB
===================================
This list is hosted by DevelopMentor. http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Ryan Heath
2008-02-19 09:25:30 UTC
Permalink
Post by Frans Bouma
Post by Chris Tavares
Don't forget that this is a POST-increment. The return value of i++ is the
original value of i, before it was incremented.
Then it makes sense. (but the compiler should throw a warning, as it's
non-obvious code. For the 99% of the C# users who don't know the spec in every
detail)
That's my whole point. The behaviour is documented but its not
obvious. So why is C# supporting this behavior?

You *could* compare it to macroes, C# does not support macroes, and I
am glad it does not.
Too often macroes led to code that was not so obvious at all...

// Ryan

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
silky
2008-02-19 09:31:02 UTC
Permalink
Post by Ryan Heath
Post by Frans Bouma
Post by Chris Tavares
Don't forget that this is a POST-increment. The return value of i++ is the
original value of i, before it was incremented.
Then it makes sense. (but the compiler should throw a warning, as it's
non-obvious code. For the 99% of the C# users who don't know the spec in every
detail)
That's my whole point. The behaviour is documented but its not
obvious. So why is C# supporting this behavior?
it is obvious. it's not even a requirement to know the spec in every detail.

c# and java have improved over c++ in their handling of the exact same
statement (as Jon said; it's undefined in that).

what isn't right is to have a statement who's result is dependant on
the compiler, not the spec.
Post by Ryan Heath
You *could* compare it to macroes, C# does not support macroes, and I
am glad it does not.
Too often macroes led to code that was not so obvious at all...
this is not code that any sane person should ever write. but should
they do, the answer is obvious if you understand post increment. if
you don't, then okay that's fine. i'm sure there are parts of the
language that you don't understand [same as anyone else]. so what do
you do in this case? you learn. you test. you move on.

there will be more and less complicated parts of the language. it is
the way the language is. c#, hopefully, doesn't head down the path of
too much complexity/"features" in place of usability/readability. c#
2.0 has the right amount of features. 3? well, i'm not sold on that
yet :P maybe a few too many ...
Post by Ryan Heath
// Ryan
--
http://lets.coozi.com.au/

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Frans Bouma
2008-02-19 09:57:02 UTC
Permalink
Post by silky
Post by Ryan Heath
Post by Frans Bouma
Post by Chris Tavares
Don't forget that this is a POST-increment. The return value of i++ is
the
Post by Ryan Heath
Post by Frans Bouma
Post by Chris Tavares
original value of i, before it was incremented.
Then it makes sense. (but the compiler should throw a warning, as
it's
Post by Ryan Heath
Post by Frans Bouma
non-obvious code. For the 99% of the C# users who don't know the spec in
every
Post by Ryan Heath
Post by Frans Bouma
detail)
That's my whole point. The behaviour is documented but its not
obvious. So why is C# supporting this behavior?
it is obvious. it's not even a requirement to know the spec in every detail.
Well, I might sound stupid now, but I thought:
int i = 0;
int x = i++;

would result in x being 1, as I assumed that i++ would be completed
before x=i would be performed (so when x=i is performed, i would have been
increased).

The thing is this: when I do:
int i = 0;
int x = (i=i+1);

x is 1, not 0. So replacing i=i+1 with i++ (even when there are
brackets) makes the code change, while i=i+1 is thought to be the equivalent
of i++. THIS is confusing crap. One can lecture me with the spec chapters, I
don't care: if something is seen to be equivalent by many people and they're
different in these kind of occasions, something should be done to make things
more clearer so MANY MANY people make LESS mistakes. Because that's what this
is all about: The TOOLS used, i.e. the compiler, should help the developer to
make as FEW mistakes as possible. This kind of ambiguity isn't helping.

It's similar to the old-style C behavior of: Foo(i++, i);

where i is first passed and then incremented. However, what's silly is
that in C you had ++i as well, but in C# you don't. So apparently the language
designers thought it would be useful to cram some C-style syntaxis in C# to
'make them feel at home' (similar to the retarted 'break;' in case clauses)
however for situations where the int first had to be incremented and THEN
passed, there was no necessity to add that to the syntax as well... very
strange.
Post by silky
Post by Ryan Heath
You *could* compare it to macroes, C# does not support macroes, and I
am glad it does not.
Too often macroes led to code that was not so obvious at all...
this is not code that any sane person should ever write. but should
they do, the answer is obvious if you understand post increment. if
you don't, then okay that's fine. i'm sure there are parts of the
language that you don't understand [same as anyone else]. so what do
you do in this case? you learn. you test. you move on.
Well, valuable lesson learned from a lot of C code writing is that one
should avoid combining i++, ++i with other statements. So it might look fancy
to cram everything into one line, but no-one is helped by a statement like
arr[i++, ++i];. I know that in C ++i is faster than i++ due to register
voodoo, but that doesn't mean it should be combined with other statements, it
causes confusion.

SUUURREE, people who know the spec inside out and who have the idea
that everyone should know the spec as good as they do will now say: "what's
the problem? the spec is pretty clear".. Yes it is, but that doesn't make code
less error prone.

FB

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
silky
2008-02-19 10:06:23 UTC
Permalink
Post by Brady Kelly
Post by silky
Post by Ryan Heath
Post by Frans Bouma
Post by Chris Tavares
Don't forget that this is a POST-increment. The return value of i++ is
the
Post by Ryan Heath
Post by Frans Bouma
Post by Chris Tavares
original value of i, before it was incremented.
Then it makes sense. (but the compiler should throw a warning, as
it's
Post by Ryan Heath
Post by Frans Bouma
non-obvious code. For the 99% of the C# users who don't know the spec in
every
Post by Ryan Heath
Post by Frans Bouma
detail)
That's my whole point. The behaviour is documented but its not
obvious. So why is C# supporting this behavior?
it is obvious. it's not even a requirement to know the spec in every detail.
int i = 0;
int x = i++;
would result in x being 1, as I assumed that i++ would be completed
before x=i would be performed (so when x=i is performed, i would have been
increased).
int i = 0;
int x = (i=i+1);
x is 1, not 0. So replacing i=i+1 with i++ (even when there are
brackets) makes the code change, while i=i+1 is thought to be the equivalent
of i++. THIS is confusing crap.
I tested this exact same thing too :) The difference, again, [and as
you already know] is that it's specifically a "post-increment"
operator.

for example, compare:

void m (int a, int m){
Console.WriteLine("a: " + a + ", b: " + b);
}

int k = 0;
m( k = k + 1, k ); // this
m(k++, k); // with this


As you know, you'll get different results because in reality k = k + 1
and k++ are not equivelant expressions inside a statement.
Post by Brady Kelly
One can lecture me with the spec chapters, I
don't care: if something is seen to be equivalent by many people and they're
different in these kind of occasions, something should be done to make things
more clearer so MANY MANY people make LESS mistakes. Because that's what this
is all about: The TOOLS used, i.e. the compiler, should help the developer to
make as FEW mistakes as possible. This kind of ambiguity isn't helping.
Sure agreed. I do agree that the statement i = i++ is *confusing* but
at least it is *DEFINED* in c# and java. it isn't in c++.
Post by Brady Kelly
It's similar to the old-style C behavior of: Foo(i++, i);
where i is first passed and then incremented. However, what's silly is
that in C you had ++i as well, but in C# you don't.
eh? I must misunderstand you. Of course c# has ++i. and

i = ++i results in i being equal to 1;
Post by Brady Kelly
So apparently the language
designers thought it would be useful to cram some C-style syntaxis in C# to
'make them feel at home' (similar to the retarted 'break;' in case clauses)
retarded break? i like the break in case statements. what is your
issue with it, out of interest?
Post by Brady Kelly
however for situations where the int first had to be incremented and THEN
passed, there was no necessity to add that to the syntax as well... very
strange.
Post by silky
Post by Ryan Heath
You *could* compare it to macroes, C# does not support macroes, and I
am glad it does not.
Too often macroes led to code that was not so obvious at all...
this is not code that any sane person should ever write. but should
they do, the answer is obvious if you understand post increment. if
you don't, then okay that's fine. i'm sure there are parts of the
language that you don't understand [same as anyone else]. so what do
you do in this case? you learn. you test. you move on.
Well, valuable lesson learned from a lot of C code writing is that one
should avoid combining i++, ++i with other statements. So it might look fancy
to cram everything into one line, but no-one is helped by a statement like
arr[i++, ++i];. I know that in C ++i is faster than i++ due to register
voodoo, but that doesn't mean it should be combined with other statements, it
causes confusion.
agreed that it can be used in a confusing fashion.
Post by Brady Kelly
SUUURREE, people who know the spec inside out and who have the idea
that everyone should know the spec as good as they do will now say: "what's
the problem? the spec is pretty clear".. Yes it is, but that doesn't make code
less error prone.
I don't think anyone is suggesting people actually write code like
this. The point is that the answer is defined for all cases.

--
http://lets.coozi.com.au/

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Frans Bouma
2008-02-19 10:21:18 UTC
Permalink
Post by silky
Post by Frans Bouma
It's similar to the old-style C behavior of: Foo(i++, i);
where i is first passed and then incremented. However, what's
silly
Post by silky
is
Post by Frans Bouma
that in C you had ++i as well, but in C# you don't.
eh? I must misunderstand you. Of course c# has ++i. and
i = ++i results in i being equal to 1;
Yes, I made a big mistake there, I mistyped some code in my test in
snippet compiler so I based a conclusion on a typo. I shouldn't have done
that. (I never use ++n so I had to test)
Post by silky
Post by Frans Bouma
So apparently the language
designers thought it would be useful to cram some C-style syntaxis in C# to
'make them feel at home' (similar to the retarted 'break;' in case clauses)
retarded break? i like the break in case statements. what is your
issue with it, out of interest?
it doesn't add anything. There's no fall through in C#, so
switch(foo)
{
case 1:
// some code
case 2:
// some code
}

would have been OK as well. If you forget a break statement, the
compiler will whine that you have to place the break there because there's no
fall through, however the break statement itself doesn't do anything: there
was already a break in the code at that spot.

In other places where break is used, it does something: it breaks out
of the block it is in, though in switch/case it's unnecessary.

FB

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
silky
2008-02-19 10:40:30 UTC
Permalink
Post by Frans Bouma
Post by silky
Post by Frans Bouma
It's similar to the old-style C behavior of: Foo(i++, i);
where i is first passed and then incremented. However, what's
silly
Post by silky
is
Post by Frans Bouma
that in C you had ++i as well, but in C# you don't.
eh? I must misunderstand you. Of course c# has ++i. and
i = ++i results in i being equal to 1;
Yes, I made a big mistake there, I mistyped some code in my test in
snippet compiler so I based a conclusion on a typo. I shouldn't have done
that. (I never use ++n so I had to test)
Post by silky
Post by Frans Bouma
So apparently the language
designers thought it would be useful to cram some C-style syntaxis in C#
to
Post by silky
Post by Frans Bouma
'make them feel at home' (similar to the retarted 'break;' in case
clauses)
Post by silky
retarded break? i like the break in case statements. what is your
issue with it, out of interest?
it doesn't add anything. There's no fall through in C#, so
switch(foo)
{
// some code
// some code
}
would have been OK as well. If you forget a break statement, the
compiler will whine that you have to place the break there because there's no
fall through, however the break statement itself doesn't do anything: there
was already a break in the code at that spot.
there is indeed faltlhrough, just not fallthrough when you have code in one:

switch(n){
case 1:
case 2:
Console.WriteLine("a");
break;
}

// ^^ valid

switch(n){
case 1:
Console.WriteLine("m");
case 2:
Console.WriteLine("x");
break;
}

// ^^ invalid
Post by Frans Bouma
In other places where break is used, it does something: it breaks out
of the block it is in, though in switch/case it's unnecessary.
it is necessary given the above.
Post by Frans Bouma
FB
--
http://lets.coozi.com.au/

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Frans Bouma
2008-02-19 11:18:11 UTC
Permalink
Post by silky
Post by Frans Bouma
Post by silky
retarded break? i like the break in case statements. what is your
issue with it, out of interest?
it doesn't add anything. There's no fall through in C#, so
switch(foo)
{
// some code
// some code
}
would have been OK as well. If you forget a break statement, the
compiler will whine that you have to place the break there because there's
no
Post by Frans Bouma
fall through, however the break statement itself doesn't do anything: there
was already a break in the code at that spot.
switch(n){
Console.WriteLine("a");
break;
}
// ^^ valid
switch(n){
Console.WriteLine("m");
Console.WriteLine("x");
break;
}
// ^^ invalid
Post by Frans Bouma
In other places where break is used, it does something: it breaks
out
Post by Frans Bouma
of the block it is in, though in switch/case it's unnecessary.
it is necessary given the above.
No, it's not.

switch(n){
case 1:
case 2:
Console.WriteLine("a");
case 3:
Console.WriteLine("b");
}

would be perfectly fine. As there's no fall through after code blocks,
the block of case 1/2 won't end up in the block of case 3. However 'break' is
required after the code of case 2.

Anyway, it's never going to change :)

FB

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
silky
2008-02-19 11:22:42 UTC
Permalink
On Feb 19, 2008 10:18 PM, Frans Bouma <***@xs4all.nl> wrote:
[snip]
Post by Frans Bouma
Post by silky
Post by Frans Bouma
In other places where break is used, it does something: it breaks
out of the block it is in, though in switch/case it's unnecessary.
it is necessary given the above.
No, it's not.
Yes it is. What if I want to do nothing in case 1, print in case 2,
and do something in the default case? How do I do it without break?
Post by Frans Bouma
switch(n){
Console.WriteLine("a");
Console.WriteLine("b");
}
would be perfectly fine. As there's no fall through after code blocks,
the block of case 1/2 won't end up in the block of case 3. However 'break' is
required after the code of case 2.
Anyway, it's never going to change :)
FB
--
http://lets.coozi.com.au/

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Frans Bouma
2008-02-19 11:31:28 UTC
Permalink
Post by silky
[snip]
Post by Frans Bouma
Post by silky
Post by Frans Bouma
In other places where break is used, it does something: it
breaks
Post by Frans Bouma
Post by silky
Post by Frans Bouma
out of the block it is in, though in switch/case it's unnecessary.
it is necessary given the above.
No, it's not.
Yes it is. What if I want to do nothing in case 1, print in case 2,
and do something in the default case? How do I do it without break?
Do nothing in case 1 is indeed a good point. THERE a break could mean
something, and exactly the same as what break means in if/for/while etc.:
break out of the current block. So mandatory requiring a break doesn't do
that: it's unnecessary, however requiring a break, you could use break for
that, which is precisely why break is in the language. However the breaks in
case clauses with code... not necessary.

FB
Post by silky
Post by Frans Bouma
switch(n){
Console.WriteLine("a");
Console.WriteLine("b");
}
would be perfectly fine. As there's no fall through after code
blocks,
Post by Frans Bouma
the block of case 1/2 won't end up in the block of case 3. However 'break'
is
Post by Frans Bouma
required after the code of case 2.
Anyway, it's never going to change :)
FB
--
http://lets.coozi.com.au/
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
===================================
This list is hosted by DevelopMentorR http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 12:01:17 UTC
Permalink
Post by silky
Post by Frans Bouma
No, it's not.
Yes it is. What if I want to do nothing in case 1, print in case 2,
and do something in the default case? How do I do it without break?
Two options:

1) Don't include the case
2) Use a pair of empty braces, just like you would if you wanted to do
nothing in a catch block:

switch (n)
{
case 1:
{
}
case 2:
{
Console.WriteLine("Foo");
}
default:
{
// Whatever
}
}

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
silky
2008-02-19 12:09:13 UTC
Permalink
Post by Jon Skeet
Post by silky
Post by Frans Bouma
No, it's not.
Yes it is. What if I want to do nothing in case 1, print in case 2,
and do something in the default case? How do I do it without break?
1) Don't include the case
Won't work because then you'll hit the default case.
Post by Jon Skeet
2) Use a pair of empty braces, just like you would if you wanted to do
Okay, I will believe you that that works :)
Post by Jon Skeet
switch (n)
{
{
}
{
Console.WriteLine("Foo");
}
{
// Whatever
}
}
Jon
--
http://lets.coozi.com.au/

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 12:18:22 UTC
Permalink
Post by Jon Skeet
Post by silky
Post by Frans Bouma
No, it's not.
Yes it is. What if I want to do nothing in case 1, print in case 2,
and do something in the default case? How do I do it without break?
1) Don't include the case
<snip>

Just before anyone else replies - yes, I now see why that isn't an
option, due to the default case. Option 2 (empty braces) would still be
fine though.

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Peter Obiefuna
2008-02-19 16:56:35 UTC
Permalink
the
Post by Frans Bouma
compiler will whine that you have to place the break there because there's
no
Post by Frans Bouma
fall through, however the break statement itself doesn't do anything: there
was already a break in the code at that spot.
It will be easy for C# to support implicit 'break's. Afterall, there are
other breaking semantics like return, throw, goto) that remove the need for
explictbreaks in the switch construct.

Regardless, however, one thing about languages is that some things are there
for function and others are there for expressiveness, readability and sheer
documentation. How much is too much? Good question, but I don't know. The
downside with 'implicit-everywhere' is that it forces you as a language
designer to make a lot more assumptions about how people are going to use
your language. And that sometimes could be limiting.

For example, right from C# 1.0, type resolution/coercion was built into the
language (hence, function overloading support). Yet, 'var' type induction
showed up much, much later and retains only limited use (compared to how it
is used in the scripting languages). Why is that?

Perhaps because the following code,

bool recycledFromPool ;
IPerson employee = PersonFactory.GetEmployee(out recycledFromPool);

is probably better documentation (ie: shows clearer programmer intent) than

var recycledFromPool;
var employee = PersonFactory.GetEmployee(recycledFromPool);

because of the explicit type declaration of IPerson and the explicit passing
convention of poolSize.


In some programming philosophies, the following would be an equivalent
construct;

@recycledFromPool
@employee = factory :employee @recycledFromPool

The following can be said of the last construct:
1. It use shorter keystrokes.
2. It appears simpler.
3. It has to be strong on convention (the compiler or runtime has to
know where the factory for Employee is located.
4. If you 'declare' a variable more than once in error, the latest
becomes it. Sorry Princess!!
4. The compiler has to be very forgiving
(hanging-your-runtime-nose-out-to-dry).
5. It has no mechanism for enforcing contracts (Interface or otherwise).
6. It's runtime will need a facility (redirection or exception) called
something like "MethodNotFound"!

While these may suit some target audience, project size, experience set, and
the ratio of senior:junior coders on the team, it may not hold up for large
projects where many juniors have to help out with minimal supervision.


P

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Brady Kelly
2008-02-19 11:26:48 UTC
Permalink
Post by silky
switch(n){
Console.WriteLine("a");
Console.WriteLine("b");
}
would be perfectly fine. As there's no fall through after code blocks,
the block of case 1/2 won't end up in the block of case 3. However 'break' is
required after the code of case 2.
Anyway, it's never going to change :)
FB
The uninvited 'break' is even required after the code of case 3.

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 10:53:27 UTC
Permalink
silky wrote:

<snip>
Post by silky
Post by Frans Bouma
In other places where break is used, it does something: it breaks out
of the block it is in, though in switch/case it's unnecessary.
it is necessary given the above.
I don't think so, actually.

The language differentiates between the labels and the block of code
itself - you can have multiple switch-labels within a switch-section,
but there's no fall through from one switch-section to the next.

The compiler enforces "no fall through" by stating that it's an error
for the end of a switch-section to be reachable. It doesn't *have* to do
that. It would have been perfectly possible to define the language such
that break was unnecessary - they chose not to, that's all.

Unfortunately it's a bit too late to change that now, but I think it's
still regrettable.

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 10:08:42 UTC
Permalink
Frans Bouma wrote:

<snip>
Post by Frans Bouma
x is 1, not 0. So replacing i=i+1 with i++ (even when there are
brackets) makes the code change, while i=i+1 is thought to be the equivalent
of i++.
That's your mistake - assuming that i++ is equivalent to i=i+1. It's
not, that's the pre-increment behaviour.

If people don't learn the difference between i++ and ++i but use them
anyway, how is that the language's fault?
Post by Frans Bouma
where i is first passed and then incremented. However, what's silly is
that in C you had ++i as well, but in C# you don't.
Um, in what way? ++i is perfectly valid, and *is* equivalent to i=i+1.

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 09:56:53 UTC
Permalink
Post by Ryan Heath
Post by Frans Bouma
Post by Chris Tavares
Don't forget that this is a POST-increment. The return value of i++ is the
original value of i, before it was incremented.
Then it makes sense. (but the compiler should throw a warning, as it's
non-obvious code. For the 99% of the C# users who don't know the spec in every
detail)
That's my whole point. The behaviour is documented but its not
obvious. So why is C# supporting this behavior?
What would you prefer? Do you want to forbid pre and post increments
completely?
Post by Ryan Heath
You *could* compare it to macroes, C# does not support macroes, and I
am glad it does not.
Too often macroes led to code that was not so obvious at all...
True - but this one rarely comes up. People don't often assign and
pre/post increment in the same statement, fortunately.

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Frans Bouma
2008-02-19 10:05:26 UTC
Permalink
Post by Jon Skeet
Post by Ryan Heath
Post by Frans Bouma
Post by Chris Tavares
Don't forget that this is a POST-increment. The return value of i++ is the
original value of i, before it was incremented.
Then it makes sense. (but the compiler should throw a warning, as
it's
Post by Ryan Heath
Post by Frans Bouma
non-obvious code. For the 99% of the C# users who don't know the spec in
every
Post by Ryan Heath
Post by Frans Bouma
detail)
That's my whole point. The behaviour is documented but its not
obvious. So why is C# supporting this behavior?
What would you prefer? Do you want to forbid pre and post increments
completely?
They shouldn't be able to be used in:
- assignments
- method calls.

Most people use them for incrementing an int. And I'm pretty sure that
of that group the vast majority thinks that x will be 1 after:
int a = 0;
int x = a++;
Post by Jon Skeet
Post by Ryan Heath
You *could* compare it to macroes, C# does not support macroes, and I
am glad it does not.
Too often macroes led to code that was not so obvious at all...
True - but this one rarely comes up. People don't often assign and
pre/post increment in the same statement, fortunately.
In the C/C++ world it's pretty common to use them inside code. I
wouldn't be surprised if this habit leaks through to C# as well, especially
since some constructs in C# are there precisely to make these developers feel
'at home'.

FB

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 10:11:04 UTC
Permalink
Post by Frans Bouma
Post by Jon Skeet
What would you prefer? Do you want to forbid pre and post increments
completely?
- assignments
- method calls.
Most people use them for incrementing an int. And I'm pretty sure that
int a = 0;
int x = a++;
They're just expressions though - how would you go about forbidding
their use without completely mangling the language.

Also, it can be very handy to use it as an argument for a method call -
so long as you know what you're doing.

As I keep saying, avoid cargo cult programming - if you make sure you
know what your code means, you'll be okay.
Post by Frans Bouma
Post by Jon Skeet
Post by Ryan Heath
You *could* compare it to macroes, C# does not support macroes, and I
am glad it does not.
Too often macroes led to code that was not so obvious at all...
True - but this one rarely comes up. People don't often assign and
pre/post increment in the same statement, fortunately.
In the C/C++ world it's pretty common to use them inside code. I
wouldn't be surprised if this habit leaks through to C# as well, especially
since some constructs in C# are there precisely to make these developers feel
'at home'.
I've very rarely seen this to be a problem on the newsgroups.
Occasionally, yes - but there are much more frequent issues, and it's
easy enough to point out that it's a bad idea.

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Brady Kelly
2008-02-19 10:20:08 UTC
Permalink
Post by Jon Skeet
True - but this one rarely comes up. People don't often assign and
pre/post increment in the same statement, fortunately.
Jon
This issue originally appeared in the CodeProject Coding Horrors forum[1],
under the Captain Obvious thread.

[1] http://www.codeproject.com/Feature/CodingHorrors.aspx

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Brady Kelly
2008-02-19 08:15:55 UTC
Permalink
Post by Jon Skeet
int tmp = i;
i = i + 1;
tmp = i;
In other words, the increment happens after the evaluation of i, but
before the assignment - so the assignment just sets it back to the
original value.
Jon
Jon, I have just figured it out the same, but I think you mean your last
step to be i = tmp, so

i is 0

<begin i++>
tmp = i
i += 1
<end i++>

i = tmp

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 08:39:36 UTC
Permalink
Post by Brady Kelly
Post by Jon Skeet
int tmp = i;
i = i + 1;
tmp = i;
In other words, the increment happens after the evaluation of i, but
before the assignment - so the assignment just sets it back to the
original value.
Jon, I have just figured it out the same, but I think you mean your last
step to be i = tmp, so
i is 0
<begin i++>
tmp = i
i += 1
<end i++>
i = tmp
Absolutely. Sorry about that :)

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Per Bolmstedt
2008-02-19 08:27:05 UTC
Permalink
The question was why was i _still_ zero on the second loop iteration,
after it should have been post-incremented.
Since terminology seems to be important here: it *was* post-incremented. You
just didn't keep the post-incremented value.

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Brady Kelly
2008-02-19 08:57:31 UTC
Permalink
Post by Per Bolmstedt
Since terminology seems to be important here: it *was* post-incremented.
You just didn't keep the post-incremented value.

It would be very presumptuous to think something like terminology would not
enjoy a very high ranking on a list such as this ;-)

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Per Bolmstedt
2008-02-19 08:53:31 UTC
Permalink
Post by Brady Kelly
Post by Per Bolmstedt
Since terminology seems to be important here: it *was*
post-incremented. You just didn't keep the post-incremented value.
It would be very presumptuous to think something like terminology would
not enjoy a very high ranking on a list such as this ;-)
Maybe something was lost in translation; I'm not a native English speaker. I
meant terminology as in "the technical or special terms used in a business,
art, science, or special subject".

But I still think the *real* confusion here was which i you were actually
incrementing. If you had asked for 2 volunteers, named one "i", and the
other "1", and then acted the original loop out using real people, I think
the whole matter would have been perfectly clear. ;]

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
silky
2008-02-19 09:10:12 UTC
Permalink
Post by Per Bolmstedt
Post by Brady Kelly
Post by Per Bolmstedt
Since terminology seems to be important here: it *was*
post-incremented. You just didn't keep the post-incremented value.
It would be very presumptuous to think something like terminology would
not enjoy a very high ranking on a list such as this ;-)
Maybe something was lost in translation; I'm not a native English speaker. I
meant terminology as in "the technical or special terms used in a business,
art, science, or special subject".
But I still think the *real* confusion here was which i you were actually
incrementing. If you had asked for 2 volunteers, named one "i", and the
other "1", and then acted the original loop out using real people, I think
the whole matter would have been perfectly clear. ;]
LOL.

That made me laugh. I hope I am not the only person who just stood up
in their office and tried to act out the assignment of "i" to "1" on
their own. Suffice to say, I had difficulty ...

--
http://lets.coozi.com.au/

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Per Bolmstedt
2008-02-19 09:47:45 UTC
Permalink
However, what's silly is that in C you had ++i as well, but in C#
you don't.
Are you drunk?

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Frans Bouma
2008-02-19 10:16:35 UTC
Permalink
Post by Per Bolmstedt
However, what's silly is that in C you had ++i as well, but in C#
you don't.
Are you drunk?
haha :) no.

Here's the thing: I used snippet compiler to test it out. Apparently I
made a mistake somewhere so code with ++i didn't compile. I assumed (never do
that) it didn't have ++x. silly mistake. My bad.

I made a mistake there.

FB

===================================
This list is hosted by DevelopMentor� http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Per Bolmstedt
2008-02-19 09:57:08 UTC
Permalink
i like the break in case statements. what is your issue with it,
out of interest?
The usual gripes with it is that it's grammatically different from the rest
of C# (at least in regard to comparable ways of achieving the same thing),
and that it has non-intuitive closure/scoping behavior. Didn't Jon write
about this in more detail recently?

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Jon Skeet
2008-02-19 10:13:50 UTC
Permalink
Post by Per Bolmstedt
i like the break in case statements. what is your issue with it,
out of interest?
The usual gripes with it is that it's grammatically different from the rest
of C# (at least in regard to comparable ways of achieving the same thing),
and that it has non-intuitive closure/scoping behavior. Didn't Jon write
about this in more detail recently?
I'm not sure how much detail I went into, but I certainly don't like the
handling. The variable scoping is really weird, and I think it would be
much better just to enforce braces:

switch (foo)
{
case 0:
case 1:
{
...
}
case 2:
case 3:
{
...
}
}

etc.

Jon

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
Loading...