Re: Funny loop with post-increment.

On Feb 19, 2008 8:57 PM, Frans Bouma <[email protected]> wrote:
> > On Feb 19, 2008 8:25 PM, Ryan Heath <[email protected]> wrote:
> > > On Feb 19, 2008 9:44 AM, Frans Bouma <[email protected]> wrote:
> > > > > 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.
>
>         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.

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.


> 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++.


>         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;


> 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?


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


>         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