🚀 go-pugleaf

In article <767@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>Kristoffer Eriksson (ske@pkmab.se) writes:
> >Not that I necessarily agree with the first poster about always using
> >pointers for array loops, but why would you use *two* pointers? It
> >would be much more "natural" and less obscure this way:
> >
> >int a[200][2]; int *p;
> >p = &a[0][0];			/* Start from the first int of a. */
> >for (i = 0; i < 200; i++) {
> >    *(p++) = expr1(i);
> >    *(p++) = expr2(i);
> >};
>
>OK, I don't speak C, maybe this is a standard approach once you
>know the language,

Yes, it is.

> but I find Kristoffer's proposal to be at
>least as obscure as Jim Giles' right-hand example.

Jim complained about that his own example that it obscured the fact that
expr1() was stored only in a...[0], and expr2() only in a...[1], at least
that is what I think he meant. But the only thing that obscured that (in
my view), was his use of two indepent pointers to step through [0] and
[1] respectivel. It's hard to see that they don't step on each other. That
is what I perceived as his main point with the example. So I showed that
the example was badly written.

In my example above, one can easily see that expr1() and expr2() will never
be stored on each other, since thee loop just sequentially steps through
the whole a[][] array (should be easy for any C programmer at least). Not
as easy as in Jim's left hand example, but *that was not the point*!

(And if you found the initial assignment to p (p = &a[0][0]) hard to
read, that's no argument against my example, because Jim's should have
read so too. Just saying "p = &a" is wrong. And besides, "&a[0][0]" is
not that hard to read. It just takes the address of the first element
of a.)

(And if you find "++" hard to read, that only shows you are not used to C.)

> I fail to
>see any problems with the left-hand fragment which is the obvious
>way to write it.

You apparently did not read my very first sentence:
>>Not that I necessarily agree with the first poster about always using
>>pointers...

I, too, find the left-hand example slightly more readible. But Jim's
example wasn't a fair demonstration of that. Wasn't it you that in another
news group, not long ago, said you could object to unfair arguments without
necessarily disagreeing with the conclusion?... (swnet.politik)

> The other two look as the programmer's been
>training for that obsfucated (or whatever the word is) C contest.

You wouldn't win a bit with those examples.

> >[ second example]
>
>Slightly more understandable, but still obscure. It seems to assume
>that the dimension are stored in a certain order.

It is basically the same as the example above it, just written another
way. And doesn't make any more assumptions than either the one above it
or Jim's right-hand one.

> Although this probably is defined by the language,

In C arrays are written name [index1] [index2] [and_so_on], not
name [index1, index2, and_so_on], wich seems to indicate a slight
difference in the conception of arrays...

> it still seems unnecessary to rely on such a fact.

This is C, after all.

> Anyway, the human reader have to think
>a while before he can ensure that the fragment is correct.

Normally, I would use Jim's right-hand example, if for no other reason
than that it uses fewer variables, and is shorter.
-- 
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: +46 19-13 03 60  !  e-mail: ske@pkmab.se
Fax:   +46 19-11 51 03  !  or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske