a[i] = a[j]... Dangerous?

[s0suk3]

I'm a bit unclear whether a statement such as 'a[i] = a[j];' causes
undefined behavior or some other abnormalities. A statement such as
'a[i] = a[i++];' would definitely cause problems because of the double
use and side effect of 'i'. But in the former case, will the double
use of the array 'a' cause problems? Or will the right operand
('a[j]') of the assignment be evaluated first and then safely assigned
to the right operand ('a[i]')?

Thanks

[vippstar]

On Jul 3, 10:37 pm, "Robbie Hatley"
<see.my.signat. [e-mail] .addresswrote:

I'd probably seen "memmove" in the libc header before, but using
it for that application simply never occurred to me.

And even after reading the instructions for memmove, I like my
version better, because it's more obvious what's happening:

for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1]; // TRANSPARENT

Whereas with memmove, you can't "see under the hood":

memmove(blat, &blat[100], 700 * sizeof *blat); // OPAQUE

I even doubt if the compiled code is faster for memmove.
I'd guess it just uses a for loop. And if it does any
error checking, it could even be slower. (Though in
either case, we're talking maybe about 1 microsecond
every 20 minutes or so. Cheap.)

What other functions of standard C have you replaced with inline code?
It's bad practise, prone to errors and unproductive.

[Robbie Hatley]

"vippstar" wrote:

Robbie Hatley wrote:

I'd probably seen "memmove" in the libc header before, but using
it for that application simply never occurred to me.

And even after reading the instructions for memmove, I like my
version better, because it's more obvious what's happening:

for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1]; // TRANSPARENT

Whereas with memmove, you can't "see under the hood":

memmove(blat, &blat[100], 700 * sizeof *blat); // OPAQUE

I even doubt if the compiled code is faster for memmove.
I'd guess it just uses a for loop. And if it does any
error checking, it could even be slower. (Though in
either case, we're talking maybe about 1 microsecond
every 20 minutes or so. Cheap.)

What other functions of standard C have you replaced with inline
code?

Misquote. I didn't "replace" memmove with anything. As I said,
it never occured to me to use that function (at the time I wrote
the program, about 1 year ago). But even if I had known about
it at the time, I wouldn't have used it, because the hand-written
version is just as short and more transparent.

It's bad practise...

Not necessarily. If it's more clear, I'd call it GOOD practice.

... prone to errors ...

Not necessarily. If the hand-written version is simple, it's
generally no more "prone to error" than a version using a call
to a library function.

Specifically, in the "for-loop vs memmove" case you quote,
the library function is more error prone, because you have to
get three different arguments correct for it to work right.

... and unproductive ...

Nonsense. If it's more clear to the reader, then it's MORE
productive, because it takes the reader less time to understand,
and REDUCES chance of errors due to reader misunderstandin g.
(Hint: the reader may be someone other than the original author.)

Don't get me wrong, I use std library functions all the time.
But if I can do the same thing with a single, simple line of
easy-to-understand home-spun code, i'll use the home-spun
instead, because it's more TRANSPARENT:

// YES:
for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1];

// NO:
memmove(blat, &blat[100], 700 * sizeof *blat);

I save library functions for things which can NOT be easily
handled by hand-written code, such as:

// Could do this by hand, but this is MUCH easier:
if (strcomp(str1, str2)) {......}

// This one, i don't even know if it CAN be done by hand,
// and even if it could, the home-spun version probably
// wouldn't be portable:
printf("Number of employees = %d\n", NumEmp);

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[vippstar]

On Jul 4, 1:47 am, "Robbie Hatley"
<see.my.signat. [e-mail] .addresswrote:

"vippstar" wrote:

Robbie Hatley wrote:

I'd probably seen "memmove" in the libc header before, but using
it for that application simply never occurred to me.

And even after reading the instructions for memmove, I like my
version better, because it's more obvious what's happening:

for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1]; // TRANSPARENT

Whereas with memmove, you can't "see under the hood":

memmove(blat, &blat[100], 700 * sizeof *blat); // OPAQUE

I even doubt if the compiled code is faster for memmove.
I'd guess it just uses a for loop. And if it does any
error checking, it could even be slower. (Though in
either case, we're talking maybe about 1 microsecond
every 20 minutes or so. Cheap.)

What other functions of standard C have you replaced with inline
code?

Misquote. I didn't "replace" memmove with anything. As I said,
it never occured to me to use that function (at the time I wrote
the program, about 1 year ago). But even if I had known about
it at the time, I wouldn't have used it, because the hand-written
version is just as short and more transparent.

It's bad practise...

Not necessarily. If it's more clear, I'd call it GOOD practice.

... prone to errors ...

Not necessarily. If the hand-written version is simple, it's
generally no more "prone to error" than a version using a call
to a library function.

Specifically, in the "for-loop vs memmove" case you quote,
the library function is more error prone, because you have to
get three different arguments correct for it to work right.

... and unproductive ...

Nonsense. If it's more clear to the reader, then it's MORE
productive, because it takes the reader less time to understand,
and REDUCES chance of errors due to reader misunderstandin g.
(Hint: the reader may be someone other than the original author.)

Don't get me wrong, I use std library functions all the time.
But if I can do the same thing with a single, simple line of
easy-to-understand home-spun code, i'll use the home-spun
instead, because it's more TRANSPARENT:

<snip example>

This group is for C discussions. Clearly you need to be taught the
basics of programming, which I don't think I can teach you in a post
or two. I'll ignore the rest of your replies for this particular
matter, it's likely that a flame war will come out of it without
anything important discussed.

[Richard Heathfield]

[rolling one's own memmove code]

Robbie Hatley said:

>
If it's more clear to the reader, then it's MORE
productive, because it takes the reader less time to understand,
and REDUCES chance of errors due to reader misunderstandin g.
(Hint: the reader may be someone other than the original author.)

Most readers will find it easier to read memmove calls than hand-rolled
loops. Hint: for any code that is read by at least three people, most
readers are someone other than the original author.

Don't get me wrong, I use std library functions all the time.
But if I can do the same thing with a single, simple line of
easy-to-understand home-spun code, i'll use the home-spun
instead, because it's more TRANSPARENT:

The great thing about standard library functions is that they're easy to
understand because we've all used them a brazillion times before - so we
can see at a glance what the code does. If you replace the code with, say,
this:

>
// YES:
for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1];

....we have to think more carefully about whether the code is right.

>
// NO:
memmove(blat, &blat[100], 700 * sizeof *blat);

But this doesn't do the same thing! Use this instead:

memmove(blat, blat + 1, 700 * sizeof *blat);

I save library functions for things which can NOT be easily
handled by hand-written code, such as:

// Could do this by hand, but this is MUCH easier:
if (strcomp(str1, str2)) {......}

The C language doesn't define a strcomp function.

// This one, i don't even know if it CAN be done by hand,
// and even if it could, the home-spun version probably
// wouldn't be portable:
printf("Number of employees = %d\n", NumEmp);

It can, and it would be. But that doesn't mean it would be *wise*.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Kaz Kylheku]

On 2008-07-03, Robbie Hatley <se************ **@for.my.email .addresswrote:

>
"vippstar" wrote:

>Robbie Hatley wrote:

I'd probably seen "memmove" in the libc header before, but using
it for that application simply never occurred to me.

And even after reading the instructions for memmove, I like my
version better, because it's more obvious what's happening:

for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1]; // TRANSPARENT

Whereas with memmove, you can't "see under the hood":

memmove(blat, &blat[100], 700 * sizeof *blat); // OPAQUE

I even doubt if the compiled code is faster for memmove.
I'd guess it just uses a for loop. And if it does any
error checking, it could even be slower. (Though in
either case, we're talking maybe about 1 microsecond
every 20 minutes or so. Cheap.)

What other functions of standard C have you replaced with inline
code?

Misquote. I didn't "replace" memmove with anything. As I said,
it never occured to me to use that function (at the time I wrote
the program, about 1 year ago). But even if I had known about
it at the time, I wouldn't have used it, because the hand-written
version is just as short and more transparent.

>It's bad practise...

Not necessarily. If it's more clear, I'd call it GOOD practice.

>... prone to errors ...

Not necessarily. If the hand-written version is simple, it's
generally no more "prone to error" than a version using a call
to a library function.

Specifically, in the "for-loop vs memmove" case you quote,
the library function is more error prone, because you have to
get three different arguments correct for it to work right.

>... and unproductive ...

Nonsense. If it's more clear to the reader, then it's MORE
productive, because it takes the reader less time to understand,
and REDUCES chance of errors due to reader misunderstandin g.
(Hint: the reader may be someone other than the original author.)

Don't get me wrong, I use std library functions all the time.
But if I can do the same thing with a single, simple line of
easy-to-understand home-spun code, i'll use the home-spun
instead, because it's more TRANSPARENT:

Transparency is a desireable property in computer science, when
it refers to a lack of unwanted interference in data communication,
or storage access.

The kind of transparency you are talking about here simply
refers to an inline expansion of something that is abstract
to one of its possible implementation.

All you are doing is burdening the reader with more responsibility.

// YES:
for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1];

If we include the declaration of i, this is a 19 node
abstract syntax tree.

Note that we ca make a small change to the above such that
its meaning radically changes.

for ( i = 0; i < 700 ; ++i ) blat[i] += blat[i+1];

Now it's no longer doing a memmove. So you see the reader has
to analyze the code carefully; or else such a little
detail can easily be missed.

// NO:
memmove(blat, &blat[100], 700 * sizeof *blat);

This is a 10 node abstract syntax tree. Only 9 if we change
&blat[100] to blat + 100.

You're saying it's okay to bloat up code by a factor of 1.9
to avoid using a library function.

And that's just the increase in raw synactic complexity.
There is an increase in semantic complexity also.

The meaning of the code is ``copy this much data from here
to there''. The memcpy call simply states that meaning!
It's a primitive, well-understood operation.

The expanded algorithm does /not/ just state that meaning;
the meaning emerges from the relationship of the individual
steps of the algorithm, as it unfolds in time.

I save library functions for things which can NOT be easily
handled by hand-written code, such as:

// Could do this by hand, but this is MUCH easier:
if (strcomp(str1, str2)) {......}

The function is called strcmp, not strcomp. (Are you sure you use it?)

The above code can be inlined with a syntactic bloat of over 3.

This, of course, is worse than 1.9, but not much:

// 5 node syntax tree

if (strcmp(s1, s2)) statement;

// 16 node syntax tree

while (*s1 && *s2)
if (*s1++ != *s2++) {
statement;
break;
}

The professional programmer won't tolerate any increase in syntactic
complexity for the sake of avoiding the use of a standard library function.
The exception would be when he is optimizing.

[Willem]

Kaz Kylheku wrote:
) The function is called strcmp, not strcomp. (Are you sure you use it?)

Perhaps he's speaking of some non-standard function that compares
case-insensitively (similar to the also non-standard strcasecmp)

) The professional programmer won't tolerate any increase in syntactic
) complexity for the sake of avoiding the use of a standard library function.
) The exception would be when he is optimizing.

In which case he should (IMO) keep the library function call that he's
replacing in a comment.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[Robbie Hatley]

Who let this troll in here?

"<vi******@gmai l.com>" spewed:

This group is for C discussions. Clearly you need to be taught the
basics of programming, which I don't think I can teach you in a post
or two. I'll ignore the rest of your replies for this particular
matter, it's likely that a flame war will come out of it without
anything important discussed.

On Usenet, I only talk to people who are capable of cordial,
on-topic, non-ad-hominem conversations. Clearly, you are not.

::: killfiles vi******@gmail. com :::

Buh-bye.

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[Robbie Hatley]

Richard Heathfield wrote:

Robbie Hatley said:

// YES:
for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1];

...we have to think more carefully about whether the code
is right....

Typo. Scroll up a couple of messages, and you'll see it
started out like this:

for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+100];

Dunno how the two zeros got cut out.

// NO:
memmove(blat, &blat[100], 700 * sizeof *blat);

But this doesn't do the same thing!

It does, if you put the zeros back.

Use this instead:

memmove(blat, blat + 1, 700 * sizeof *blat);

No, a correct version would be:

memmove(blat, blat + 100, 700 * sizeof *blat);

But I MUCH prefer:

for ( i = 0 ; i < 700 ; ++i ) blat[i] = blat[i+100];

Because it says EXACTLY what it does, and EXACTLY how
it does it, in 52 characters, 14 of which are whitespace.

Whereas, memmove is an opaque "black box".

The C language doesn't define a strcomp function.

Typo. strcmp. Don't be silly; you can intuit that.

// This one, i don't even know if it CAN be done by hand,
// and even if it could, the home-spun version probably
// wouldn't be portable:
printf("Number of employees = %d\n", NumEmp);

It can, and it would be. But that doesn't mean it would
be *wise*.

Of course it's not wise. I never said it was. In fact,
I said the opposite. There are times and places for
library functions. Printing things is one of those.
But in my opinion, shifting some data 100 bytes to the
left is not.

--
for (i = 0; i < 700; ++i) blat[i] = blat[i+100]; /* :-P */
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[Robbie Hatley]

"Kaz Kylheku" <kk******@gmail .comwrote:

The kind of transparency you are talking about here simply
refers to an inline expansion of something that is abstract
to one of its possible implementation.

Misquote. I never "expanded" memmove. memmove was never in
the program to begin with! You really do need to READ what
you're replying to, before replying to it.

The for loop in question wasn't "one possible implimentation
of memmove"; it wan't an attempt to impliment memmove at all!
It was written for one specific application in which I needed
to shift some data in a "partial-overwrite" fashion, while
insuring the following:

1. That the over-write destroys ONLY the oldest 100 bytes.
2. That the exact method was as I desired.
3. That the method be transparent to the reader.

A simple 1-line for loop, easily understandable by even
a newbie at C, served admirably.

All you are doing is burdening the reader with more
responsibility.

No. Library functions require looking-up syntax and
semantics, whereas for loops and pointers are part of the
basic language. So in those rare cases where the hand-
written version is simpler (clearer to the reader) than
a library function call, I tend to write it by hand.

... the reader has to analyze the code carefully; or else
such a little detail can easily be missed...

Always true when reading code, REGARDLESS of whether library
functions are used or not.

... This is a 10 node abstract syntax tree....

I think you're over-technicalizing a simple thing.
I just go by what WORKS, and what is CLEAR, "abstract
syntax trees" not withstanding.

The expanded algorithm does /not/ just state that meaning;
the meaning emerges from the relationship of the individual
steps of the algorithm, as it unfolds in time.

Some don't grok C. C'est la vie. If my boss hires someone
who can't understand for loops, that's his loss, not mine.

The professional programmer won't tolerate any increase in
syntactic complexity for the sake of avoiding the use of
a standard library function. The exception would be when
he is optimizing.

A mostly-true platitude. But like all platitudes, it has
it's limits of applicability, and if over-relied-on, can
be as harmful as it is helpful.

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[Robbie Hatley]

"Willem" <wi****@stack.n lwrote:

... he [Robbie Hatley] should (IMO) keep the library function
call that he's replacing in a comment....

Misquote. I never replaced any library function call. I wrote
the code in question from scratch, electing not to use any
library function calls.

Where are people get this "replaced a library function call"
stuff from? I never said that anywhere! I believe it was the
person calling hirself "vipstarr" who said I "replaced a library
function call", not me. I've placed that person in my killfile
due to obnoxiousness, trolling, and apparently-on-purpose misquotes.
Maybe this person is the finest fellow in the world and is just in
a bad mood today, but on Usenet, I can only judge by what I read.

This is the danger of replying to a reply to a reply to a reply
to a reply to a reply to something an OP said. Gets confusing,
doesn't it? You end up misquoting and misunderstandin g things.
Hence, best not to do that.

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant