Re: Funny loop with post-increment.

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

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