Double increment question.

[Robbie Hatley]

Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies.

Specificially, I just wrote the following, but I don't know if this
is safe:

void Func(char* left, char* right)
{
chat temp_left [17] = {'\0'};
chat temp_right [17] = {'\0'};
int i;
char *ptr1, *ptr2;

/* ... do some stuff ... */

/* Copy the left part to temp_left: */
ptr1 = temp_left;
ptr2 = left;
while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

/* ... do some other stuff ... */

return;
}

I'm pretty sure that's a conceptually sound way of copying the characters
starting at address "left", up-to-but-not-including address "right",
to array "temp_left".

But my question is, will I get into trouble with that double increment?
Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
either increment occurs???

Sorry if this seems like a dorky question. I'm rusty.

--
Cheers,
Robbie Hatley
East Tustin, CA, USA
lone wolf intj at pac bell dot net
(put "[usenet]" in subject to bypass spam filter)
home dot pac bell dot net slant earnur slant

[Richard Riley]

"Robbie Hatley" <bo***********@no.spamwrites:

Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies.

while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
either increment occurs???

Yes. Same as in C++ when dealing with char pointers isnt it?

[spibou]

Robbie Hatley wrote:

Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies.

Specificially, I just wrote the following, but I don't know if this
is safe:

void Func(char* left, char* right)
{
chat temp_left [17] = {'\0'};
chat temp_right [17] = {'\0'};
int i;
char *ptr1, *ptr2;

/* ... do some stuff ... */

/* Copy the left part to temp_left: */
ptr1 = temp_left;
ptr2 = left;
while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

/* ... do some other stuff ... */

return;
}

I'm pretty sure that's a conceptually sound way of copying the characters
starting at address "left", up-to-but-not-including address "right",
to array "temp_left".

I assume chat was meant to be char. I assume also i is used
in the part of the code not given.

But my question is, will I get into trouble with that double increment?
Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
either increment occurs???

Strictly speaking , what is guaranteed is that the location ptr2 points
to
before the increment will be assigned the value from the location ptr1
points to before the increment. But whether this assignment occurs
before the pointers have been inceremented is up to the implementation.

Spiros Bousbouras

[BubbaGump]

On Tue, 25 Jul 2006 03:31:33 GMT, "Robbie Hatley"
<bo***********@no.spamwrote:

>Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies.

Specificially, I just wrote the following, but I don't know if this
is safe:

void Func(char* left, char* right)
{
chat temp_left [17] = {'\0'};
chat temp_right [17] = {'\0'};
int i;
char *ptr1, *ptr2;

/* ... do some stuff ... */

/* Copy the left part to temp_left: */
ptr1 = temp_left;
ptr2 = left;
while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

/* ... do some other stuff ... */

return;
}

I'm pretty sure that's a conceptually sound way of copying the characters
starting at address "left", up-to-but-not-including address "right",
to array "temp_left".

But my question is, will I get into trouble with that double increment?
Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
either increment occurs???

Sorry if this seems like a dorky question. I'm rusty.

You find breaking up the operations into a form that's more obvious to
be objectionable?

while (ptr2 < right) {
*ptr1 = *ptr2;
ptr1++;
ptr2++;
}

[Robbie Hatley]

"Richard Riley" wrote:

"Robbie Hatley" <bo***********@no.spamwrites:

Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies:
while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???
Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
either increment occurs???

Yes.

Thanks.

Same as in C++ when dealing with char pointers isnt it?

If it works that way with the one, I suppose it does with the
other. However, my usual way of coping strings in C++ is:

std::string str1 ("Fred"); // make string str1 containing "Fred"
std::string str2 (str1); // make string str2 and copy str1 to str2

A bit simpler than in C. :-)

--
Cheers,
Robbie Hatley
East Tustin, CA, USA
lone wolf intj at pac bell dot net
(put "[usenet]" in subject to bypass spam filter)
home dot pac bell dot net slant earnur slant

[Robbie Hatley]

<sp****@gmail.comwrote:

Robbie Hatley wrote:

Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies.

Specificially, I just wrote the following, but I don't know if this
is safe:

void Func(char* left, char* right)
{
chat temp_left [17] = {'\0'};
chat temp_right [17] = {'\0'};
int i;
char *ptr1, *ptr2;

/* ... do some stuff ... */

/* Copy the left part to temp_left: */
ptr1 = temp_left;
ptr2 = left;
while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

/* ... do some other stuff ... */

return;
}

I'm pretty sure that's a conceptually sound way of copying the characters
starting at address "left", up-to-but-not-including address "right",
to array "temp_left".

I assume chat was meant to be char. I assume also i is used
in the part of the code not given.

I was typing an excerpt from a larger function. I should have used
copy-'n'-paste instead, then deleted the excess junk. (The "chat" was
actually in the original, though. I'd not tried to compile it yet,
because I was worried about the run-time effects of the increments.)

But my question is, will I get into trouble with that double increment?
Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
either increment occurs???

Strictly speaking , what is guaranteed is that the location ptr2
points to before the increment will be assigned the value from the
location ptr1 points to before the increment. But whether this
assignment occurs before the pointers have been inceremented is up
to the implementation.

That's the important thing. As long as stuff is copied from the
correct source locations to the correct destination locations, all
is well.

--
Cheers,
Robbie Hatley
East Tustin, CA, USA
lone wolf intj at pac bell dot net
(put "[usenet]" in subject to bypass spam filter)
home dot pac bell dot net slant earnur slant

[Flash Gordon]

BubbaGump wrote:

On Tue, 25 Jul 2006 03:31:33 GMT, "Robbie Hatley"
<bo***********@no.spamwrote:

<snip>

> while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

<snip>

You find breaking up the operations into a form that's more obvious to
be objectionable?

while (ptr2 < right) {
*ptr1 = *ptr2;
ptr1++;
ptr2++;
}

The code posted by Robbie Hatley is idiomatic C, so whether you like it
or not to be competent you have to understand it.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Richard Heathfield]

Robbie Hatley said:

Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies.

Specificially, I just wrote the following, but I don't know if this
is safe:

It isn't, but perhaps not for the reason you imagine.

void Func(char* left, char* right)
{
chat temp_left [17] = {'\0'};
chat temp_right [17] = {'\0'};
int i;
char *ptr1, *ptr2;

/* ... do some stuff ... */

/* Copy the left part to temp_left: */
ptr1 = temp_left;
ptr2 = left;
while (ptr2 < right)

This comparison compares the ptr2 pointer value with a pointer to a
completely different object. Bad idea, unless you know for sure (and how
can you?) that 'right' is actually a pointer into the same object that
'left' points to.

*ptr1++ = *ptr2++; // WILL THIS WORK???

Yes, because ptr1 and ptr2 do not at any time point to the same char. But
even so, wouldn't it be easier to work out how many bytes you want to copy
and just memcpy them?

I'm pretty sure that's a conceptually sound way

Yes...

of copying the characters starting at address "left",

....and yes...

up-to-but-not-including address "right",

....and no, unless you can guarantee that 'right' points into the same
object.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chris Dollin]

BubbaGump wrote:

On Tue, 25 Jul 2006 03:31:33 GMT, "Robbie Hatley"
<bo***********@no.spamwrote:

(fx:snip)

> while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

(fx:snip)

You find breaking up the operations into a form that's more obvious to
be objectionable?

while (ptr2 < right) {
*ptr1 = *ptr2;
ptr1++;
ptr2++;
}

I find the former more obvious than the latter. It's idiomatic, it's
presented compactly enough to see it as a unit, and it's harder to make
the mistake of incrementing the wrong variable or forgetting to
increment a variable.

I'm not really worried about code being inobvious to people who
are new to the language: not all code is suitable for tutorial
use.

The second form is more /explicit/, certainly.

--
Chris "or /tedious/" Dollin
This .signature temporarily left blank.

[Robbie Hatley]

<BubbaGumpwrote:

Robbie Hatley wrote:

while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

You find breaking up the operations into a form that's more
obvious to be objectionable?

while (ptr2 < right) {
*ptr1 = *ptr2;
ptr1++;
ptr2++;
}

A few years ago, I would have preferred that, yes. These days,
however, something like:

while (ptr2 < right) *ptr1++ = *ptr2++;

actually looks more "obvious" to me. At least, I understand the intent
of the author instantly. Whether or not the sequence points work out
right in such code is a different matter! It's so easy to make blunders
like that. But my friend Ron, the firmware guru, uses code like that
all the time without having it blow up on him. A matter of experience.

I was just googling "sequence point", trying to find more info on this,
and I ran across http://c-faq.com/ which is, lo and behold, the FAQ for
this group. That site mentions the following two sentences from the
C standard:

Between the previous and next sequence point an object shall
have its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be accessed
only to determine the value to be stored.

After staring at those for a while I think I understand them.
If I'm getting the idea right, it says:

1. You aren't supposed to alter the same variable twice between
sequence points.
2. If you alter a variable between two sequence points, you're
not supposed to use the original value of that variable for
any purpose other than computing the final value to be stored
back into the variable.

For example, I think the following violates those rules:

int main()
{
int y=0;
int x=7;
y = 2*x + x++; // violates sentence 2?
printf("y = %d", y); // prints 21? or 22?

y=0;
x=7;
y = x++ + x++; // violates sentences 1 and 2?
printf("y = %d", y); // prints 14? or 15?

return 0;
}

Looks to me like both of those calculations are undefined.
Do I have that right?

--
Cheers,
Robbie Hatley
East Tustin, CA, USA
lone wolf intj at pac bell dot net
(put "[usenet]" in subject to bypass spam filter)
home dot pac bell dot net slant earnur slant

[Robbie Hatley]

Richard Heathfield wrote:

Robbie Hatley said:

...
void Func(char* left, char* right)
{
...
while (ptr2 < right)

This comparison compares the ptr2 pointer value with a pointer to a
completely different object. Bad idea, unless you know for sure (and how
can you?) that 'right' is actually a pointer into the same object that
'left' points to.

That's actually not a danger here. It's taken care of in the chopped-out
part. Also, with one exception, the only caller of Func is Func
(it's recursive), so it controls what "left" and "right" point to.

*ptr1++ = *ptr2++; // WILL THIS WORK???

Yes, because ptr1 and ptr2 do not at any time point to the same char. But
even so, wouldn't it be easier to work out how many bytes you want to copy
and just memcpy them?

memcpy did occur to me, yes. But I'm writing a program which I want to
be as small and fast as possible, so I'm doing things "manually".
If the MyProgram.exe file is 47 bytes and processes 8TB of data in 3.5ns,
that wouldn't be too small or fast for my taste. (Pardon my exageration.)
I'm not even #including <stdlib.h>. The only #include is <stdio.h>, and
if I could figure out how to print to stdout without that, I would.

--
Cheers,
Robbie Hatley
East Tustin, CA, USA
lone wolf intj at pac bell dot net
(put "[usenet]" in subject to bypass spam filter)
home dot pac bell dot net slant earnur slant

[Richard Heathfield]

Robbie Hatley said:

<snip>

>
For example, I think the following violates those rules:

int main()
{
int y=0;
int x=7;
y = 2*x + x++; // violates sentence 2?

Yes.

printf("y = %d", y); // prints 21? or 22?

Or nothing. Or "banana". Quite apart from the undefined behaviour you
invoked in the previous line, you're calling a variadic function without a
valid prototype in scope.

y=0;
x=7;
y = x++ + x++; // violates sentences 1 and 2?

Yes.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Robbie Hatley said:

>
Richard Heathfield wrote:

<snip>

>wouldn't it be easier to work out how many bytes you want to
copy and just memcpy them?

memcpy did occur to me, yes. But I'm writing a program which I want to
be as small and fast as possible,

memcpy is likely to be faster than byte-by-byte copying for even moderate
volumes of data. Why? Because it's got a fighting chance of being
implemented as hand-rolled assembly language, packed to the gunwales with
performance-enhancing drugs.

so I'm doing things "manually".

So why not go the whole hog and use pencil and paper? ;-)

If the MyProgram.exe file is 47 bytes and processes 8TB of data in 3.5ns,
that wouldn't be too small or fast for my taste. (Pardon my exageration.)
I'm not even #including <stdlib.h>.

How does its omission speed up your program?

The only #include is <stdio.h>, and
if I could figure out how to print to stdout without that, I would.

int putchar(int);

int main(void)
{
int ch = '\n';
putchar(ch);
return 0;
}

But omitting stdio.h won't speed up your program either.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Flash Gordon]

Robbie Hatley wrote:

<snip>

A few years ago, I would have preferred that, yes. These days,
however, something like:

while (ptr2 < right) *ptr1++ = *ptr2++;

actually looks more "obvious" to me. At least, I understand the intent
of the author instantly. Whether or not the sequence points work out
right in such code is a different matter! It's so easy to make blunders
like that. But my friend Ron, the firmware guru, uses code like that
all the time without having it blow up on him. A matter of experience.

Knowledge of the language as well.

I was just googling "sequence point", trying to find more info on this,
and I ran across http://c-faq.com/ which is, lo and behold, the FAQ for
this group.

It is very good reading material.

That site mentions the following two sentences from the
C standard:

Between the previous and next sequence point an object shall
have its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be accessed
only to determine the value to be stored.

After staring at those for a while I think I understand them.
If I'm getting the idea right, it says:

1. You aren't supposed to alter the same variable twice between
sequence points.
2. If you alter a variable between two sequence points, you're
not supposed to use the original value of that variable for
any purpose other than computing the final value to be stored
back into the variable.

For example, I think the following violates those rules:

int main()
{
int y=0;
int x=7;
y = 2*x + x++; // violates sentence 2?

Correct.

printf("y = %d", y); // prints 21? or 22?

Or anything else or nothing at all. Violating the sequence point rule
means that *anything* is allowed to happen, including it causing your
mother-in-law to move in permanently. A slightly more plausible but very
damaging scenario that could occur is wrecking the processor due to a
bus collision. Imagine a processor with multiple data buses, so it can
simultaneously write to multiple memory location in its cache. Imagine
further that the processor does not validate that parallel accesses are
actually to different locations. Since the compiler is not required to
do anything in particular it could generate code that wrote the result
of incrementing x simultaneously with reading x to calculate 2*x, and
this could damage the processor.

y=0;
x=7;
y = x++ + x++; // violates sentences 1 and 2?

Yes. It is also one of the "classic" examples.

printf("y = %d", y); // prints 14? or 15?

Or it could do anything else.

return 0;
}

Looks to me like both of those calculations are undefined.
Do I have that right?

Yes. All yo have not got is that the results of undefined behaviour can
be even stranger than you can imagine.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Eric Sosman]

Robbie Hatley wrote:

[...]
memcpy did occur to me, yes. But I'm writing a program which I want to
be as small and fast as possible, so I'm doing things "manually". [...]

Digging a hole in the ground is a wearisome and tedious
task, and I'd like it to take as little time as possible.
That's why I told that guy with the backhoe to go somewhere
else, threw away my silly old shovel, and am now "doing things
manually" by scrabbling in the dirt with my fingernails. ;-)

More seriously, it seems more than a little likely that
you are committing the sin of premature optimization. Until
and unless you have MEASURED a performance problem -- not
hypothecated, not supposed, not "it stands to reason-ed" --
until you have made MEASUREMENTS it is irresponsible folly to
micro-optimize.

"Premature optimization is the root of all evil."
-- D.E. Knuth

"We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

"More computing sins are committed in the name of efficiency
(without necessarily achieving it) than for any other single
reason, including blind stupidity."
-- W.A. Wulf

In other words, I'm not the only person crying that ab initio
micro-optimization is folly; smart people do so, too. Be smart.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Frederick Gotham]

Robbie Hatley posted:

while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

Yes, assuming the function is invoked somewhat like the following:

int main(void)
{
char const str[] = "Hello, I'm a dog.";

Func(str, str[7]);
}

If "right" were to refer to a totally different string, you'd have undefined
behaviour.

--

Frederick Gotham

[Richard Heathfield]

Frederick Gotham said:

Robbie Hatley posted:

> while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

Yes, assuming the function is invoked somewhat like the following:

int main(void)
{
char const str[] = "Hello, I'm a dog.";

Func(str, str[7]);

Either you meant &str[7] or str + 7. And the const breaks the Func call,
since Func takes char *, not const char * (see OP).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Frederick Gotham]

Richard Heathfield posted:

>int main(void)
{
char const str[] = "Hello, I'm a dog.";

Func(str, str[7]);

Either you meant &str[7] or str + 7.

Indeed I meant:

str + 7

And the const breaks the Func call,
since Func takes char *, not const char * (see OP).

....but the function signature is broken : )

--

Frederick Gotham

[BubbaGump]

On 25 Jul 2006 10:01:09 +0200, Flash Gordon <sp**@flash-gordon.me.uk>
wrote:

>BubbaGump wrote:

>On Tue, 25 Jul 2006 03:31:33 GMT, "Robbie Hatley"
<bo***********@no.spamwrote:

<snip>

>> while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

<snip>

>You find breaking up the operations into a form that's more obvious to
be objectionable?

while (ptr2 < right) {
*ptr1 = *ptr2;
ptr1++;
ptr2++;
}

The code posted by Robbie Hatley is idiomatic C, so whether you like it
or not to be competent you have to understand it.

Yes, it's good to understand it so go explain away, but I was
questioning why he was trying to use it.

Also, I don't believe competence requires complete understanding.

[Flash Gordon]

BubbaGump wrote:

On 25 Jul 2006 10:01:09 +0200, Flash Gordon <sp**@flash-gordon.me.uk>
wrote:

>BubbaGump wrote:

>>On Tue, 25 Jul 2006 03:31:33 GMT, "Robbie Hatley"
<bo***********@no.spamwrote:

<snip>

>>> while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???

<snip>

>>You find breaking up the operations into a form that's more obvious to
be objectionable?

while (ptr2 < right) {
*ptr1 = *ptr2;
ptr1++;
ptr2++;
}

The code posted by Robbie Hatley is idiomatic C, so whether you like it
or not to be competent you have to understand it.

Yes, it's good to understand it so go explain away, but I was
questioning why he was trying to use it.

Because he wants to write idiomatic C?

Also, I don't believe competence requires complete understanding.

Not complete understanding of everything, no, but to be competent in a
language you have to understand the common idioms, and *dst++ = *src++
is an *extremely* common idiom in C and so needs to be understood.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[av]

On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:

>Robbie Hatley wrote:

>[...]
memcpy did occur to me, yes. But I'm writing a program which I want to
be as small and fast as possible, so I'm doing things "manually". [...]

Digging a hole in the ground is a wearisome and tedious
task, and I'd like it to take as little time as possible.
That's why I told that guy with the backhoe to go somewhere
else, threw away my silly old shovel, and am now "doing things
manually" by scrabbling in the dirt with my fingernails. ;-)

More seriously, it seems more than a little likely that
you are committing the sin of premature optimization. Until
and unless you have MEASURED a performance problem -- not
hypothecated, not supposed, not "it stands to reason-ed" --
until you have made MEASUREMENTS it is irresponsible folly to
micro-optimize.

"Premature optimization is the root of all evil."
-- D.E. Knuth

don't know

"We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

these rules are wrong

"More computing sins are committed in the name of efficiency
(without necessarily achieving it) than for any other single
reason, including blind stupidity."
-- W.A. Wulf

this can be for the c language too (that would find the speed with 0
terminated string but find only difficulties and buffers overflows)
it seems i can think of a string class that do everyting more simple
and with no possible errors in each its 'atomic' operations

In other words, I'm not the only person crying that ab initio
micro-optimization is folly; smart people do so, too. Be smart.

i not agree if assembly can reduce the executable dimendion for a
factor 10 and the code is in the cache of cpu

[av]

On Tue, 25 Jul 2006 07:58:19 GMT, Robbie Hatley wrote:

>"Richard Riley" wrote:

>"Robbie Hatley" <bo***********@no.spamwrites:

Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies:
while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???
Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
either increment occurs???

Yes.

Thanks.

>Same as in C++ when dealing with char pointers isnt it?

If it works that way with the one, I suppose it does with the
other. However, my usual way of coping strings in C++ is:

std::string str1 ("Fred"); // make string str1 containing "Fred"
std::string str2 (str1); // make string str2 and copy str1 to str2

A bit simpler than in C. :-)

in c++ all can be more simple and secure than c

[Flash Gordon]

av wrote:

On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:

>Robbie Hatley wrote:

>>[...]
memcpy did occur to me, yes. But I'm writing a program which I want to
be as small and fast as possible, so I'm doing things "manually". [...]

Digging a hole in the ground is a wearisome and tedious
task, and I'd like it to take as little time as possible.
That's why I told that guy with the backhoe to go somewhere
else, threw away my silly old shovel, and am now "doing things
manually" by scrabbling in the dirt with my fingernails. ;-)

More seriously, it seems more than a little likely that
you are committing the sin of premature optimization. Until
and unless you have MEASURED a performance problem -- not
hypothecated, not supposed, not "it stands to reason-ed" --
until you have made MEASUREMENTS it is irresponsible folly to
micro-optimize.

"Premature optimization is the root of all evil."
-- D.E. Knuth

don't know

> "We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

these rules are wrong

What makes you think that you know better than well respected experts?

> "More computing sins are committed in the name of efficiency
(without necessarily achieving it) than for any other single
reason, including blind stupidity."
-- W.A. Wulf

this can be for the c language too (that would find the speed with 0
terminated string but find only difficulties and buffers overflows)
it seems i can think of a string class that do everyting more simple
and with no possible errors in each its 'atomic' operations

Classes are off topic here. In any case, what you are saying has nothing
significant that I can see that is relevant to optimisation. Buffer
overflows are a rather different problem, and micro-optimisation
increases the likely hood of them and other errors.

> In other words, I'm not the only person crying that ab initio
micro-optimization is folly; smart people do so, too. Be smart.

i not agree if assembly can reduce the executable dimendion for a
factor 10 and the code is in the cache of cpu

Most people will *not* be able to get anything like that level of
improvement. They are even less likely to get it whilst staying with C,
as evidence a recent thread in which someone posted what they thought
was a more efficient solution, but it was demonstrated to be generally
*less* efficient.

One is in general far more likely to achieve significant improvements be
selecting the correct algorithm and design. Only when those are optimal,
and if there is still a demonstrable problem, should one use
measurements to find the problem areas and optimise them.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Chris Dollin]

av wrote:

> "We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

these rules are wrong

Why do you think that?

Address what needs to be addressed when it needs to be addressed.

("Not optimising" doesn't mean "write stupidly slow code".)

--
Chris "slow and steady beats SIGSEGV" Dollin
"We did not have time to find out everything we wanted to know." /A Clash of Cymbals/

[av]

On Wed, 26 Jul 2006 12:19:13 +0100, Flash Gordon wrote:

>av wrote:

>On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:

>>Robbie Hatley wrote:
[...]
"Premature optimization is the root of all evil."
-- D.E. Knuth

don't know

>> "We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

these rules are wrong

What makes you think that you know better than well respected experts?

i find a lot of fun searching for optimisation code (and algorithm)
and until now not have wrong experiences
i would translate my c files in assembly and i'm sure in the
translated files, instructions will be between 1/10 and 1/100 than C
files, but the cpu has enough cache for the code and i'm lazy

>> "More computing sins are committed in the name of efficiency
(without necessarily achieving it) than for any other single
reason, including blind stupidity."
-- W.A. Wulf

this can be for the c language too (that would find the speed with 0
terminated string but find only difficulties and buffers overflows)
it seems i can think of a string class that do everyting more simple
and with no possible errors in each its 'atomic' operations

Classes are off topic here. In any case, what you are saying has nothing
significant that I can see that is relevant to optimisation. Buffer
overflows are a rather different problem, and micro-optimisation
increases the likely hood of them and other errors.

don't all you want to optimise when use 0 ended strings?
is it that a "More computing sins ..."?

>> In other words, I'm not the only person crying that ab initio
micro-optimization is folly; smart people do so, too. Be smart.

i not agree if assembly can reduce the executable dimendion for a
factor 10 and the code is in the cache of cpu

Most people will *not* be able to get anything like that level of
improvement.
They are even less likely to get it whilst staying with C,
as evidence a recent thread in which someone posted what they thought
was a more efficient solution, but it was demonstrated to be generally
*less* efficient.

think for find efficiency is never wrong because one can test the
solution. the only wrong i see is the time someone spend to think
about it. But is "to think" wrong?

>One is in general far more likely to achieve significant improvements be
selecting the correct algorithm and design. Only when those are optimal,
and if there is still a demonstrable problem, should one use
measurements to find the problem areas and optimise them.

one good idea is better that all the optimal-ways walk

[av]

On Wed, 26 Jul 2006 13:39:24 +0100, Chris Dollin wrote:

>av wrote:

>> "We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

these rules are wrong

Why do you think that?

Address what needs to be addressed when it needs to be addressed.

("Not optimising" doesn't mean "write stupidly slow code".)

i have a routine R1 that with input A has output B that follow the
algo C.
optimisation is
search a routine R2 that with input A has output B that follow an algo
H that has minimum instructions for doing calculation

are we agreeing on that definition?

why i would not try to write the "H" routine?
in my little experience errors could be in R1 too ...
and think on that routine can make to see errors in R1 too

[Andrew Poelstra]

On 2006-07-26, av <[e-mail]:

On Tue, 25 Jul 2006 07:58:19 GMT, Robbie Hatley wrote:

>>"Richard Riley" wrote:

>>"Robbie Hatley" <bo***********@no.spamwrites:

Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies:
while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???
Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
either increment occurs???

Yes.

Thanks.

>>Same as in C++ when dealing with char pointers isnt it?

If it works that way with the one, I suppose it does with the
other. However, my usual way of coping strings in C++ is:

std::string str1 ("Fred"); // make string str1 containing "Fred"
std::string str2 (str1); // make string str2 and copy str1 to str2

A bit simpler than in C. :-)

in c++ all can be more simple and secure than c

Hardly. In C you can see exactly what's happening. No black boxes, hidden
*this pointers, overridden functions, *shudder* passing by reference with
no discernable change in how you call it, and no *also shudder* overloaded
operators.

That, and a monkey could read some manpages and figure out what any line
of C does (although he obviously would be unable to recreate that or
figure out /why/ each line does what it does. Monkeys aren't the brilliant
typists that people would like us to believe.) C++ has a plethora of new
concepts, keywords, styles, etc. Not everything is simpler in C++.

Finally, C itself is not insecure. Just because you're a bad programmer
(and a lazy typist) does not mean that you should switch to a language
where your inadequacies are hidden. It means that you should learn your
language well. Buffer overflows are easy to avoid ("Don't use gets()!"
will prevent 90% of them), as are pretty well all of the common pitfalls.

--
Andrew Poelstra <website down>
My server is down; you can't mail
me, nor can I post convieniently.

[Andrew Poelstra]

On 2006-07-26, av <[e-mail]:

On Wed, 26 Jul 2006 12:19:13 +0100, Flash Gordon wrote:

>>av wrote:

>>On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:
Robbie Hatley wrote:
[...]
"Premature optimization is the root of all evil."
-- D.E. Knuth

don't know

"We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

these rules are wrong

What makes you think that you know better than well respected experts?

i find a lot of fun searching for optimisation code (and algorithm)
and until now not have wrong experiences
i would translate my c files in assembly and i'm sure in the
translated files, instructions will be between 1/10 and 1/100 than C
files, but the cpu has enough cache for the code and i'm lazy

Set the compiler to its maximum optimization level, and see whether or
not you're smarter than it.

>>One is in general far more likely to achieve significant improvements be
selecting the correct algorithm and design. Only when those are optimal,
and if there is still a demonstrable problem, should one use
measurements to find the problem areas and optimise them.

one good idea is better that all the optimal-ways walk

This is a typical sentence of yours: please use proper grammar and
punctuation, and try to make your sentences more coherant (if you
don't speak English natively, this will be harder than the others).
As it stands, I have no idea what you just said.

--
Andrew Poelstra <website down>
My server is down; you can't mail
me, nor can I post convieniently.

[Robbie Hatley]

Eric Sosman wrote of my string copy experiments:

... it seems more than a little likely that you are
committing the sin of premature optimization.

If this was a large app for long-term use by many, being
built and maintained by a team, then perhaps that might be
true.

But it's actually a tiny hobby app which I wrote expressly
for the purpose of optimization experimentation.

Until and unless you have MEASURED a performance problem
not hypothecated, not supposed, not "it stands to reason-ed"
until you have made MEASUREMENTS it is irresponsible folly to
micro-optimize.

It's already in a batch file like so:

clock
MyProgram
clock

So I can instantly see whether making a particular change
causes execution time to go up, go down, or stay about the
same.

Hypotheses must come first. Then experimentation to determine
whether your hypotheses are brilliance or bunk. That's the
scientific method.

"Premature optimization is the root of all evil."
-- D.E. Knuth

No, I think religiosity (addiction to untested ideas) is the
cause of most evil (including many bad computer programs, and
also including most wars).

"We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

That's stupid. Fear gains nothing. Say instead:
1. If you see an opportunity to optimze, do it, as long as it
doesn't significantly damage readibility or modularity.
2. Test it.
3. If it didn't significantly improve performance, revert.

"More computing sins are committed in the name of efficiency
(without necessarily achieving it) than for any other single
reason, including blind stupidity."
-- W.A. Wulf

I think far more computing sins have been commited in the name
of impatience and the desire to "get this shit done and get out
of here so I can go home and have a beer and watch the game",
as my (fired) former boss used to say.

In other words, I'm not the only person crying that ab initio
micro-optimization is folly; smart people do so, too. Be smart.

False reasoning. Imitating superficial aspects of the behavior
of smart people will not make one smart.

And while it is perhaps true that most programs should not be
"optimized ab inito", some should be.

--
Cheers,
Robbie Hatley
East Tustin, CA, USA
lone wolf intj at pac bell dot net
(put "[usenet]" in subject to bypass spam filter)
home dot pac bell dot net slant earnur slant

[Eric Sosman]

av wrote On 07/26/06 12:33,:

On Wed, 26 Jul 2006 13:39:24 +0100, Chris Dollin wrote:

>>av wrote:

>>> "We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

these rules are wrong

Why do you think that?

Address what needs to be addressed when it needs to be addressed.

("Not optimising" doesn't mean "write stupidly slow code".)

i have a routine R1 that with input A has output B that follow the
algo C.
optimisation is
search a routine R2 that with input A has output B that follow an algo
H that has minimum instructions for doing calculation

are we agreeing on that definition?

why i would not try to write the "H" routine?

To begin with, things are seldom that simple. For
example, suppose you can implement R1 in portable C but
must use assembly language for R2. This means you need
to re-implement R2 every time you move to a new machine;
if you really think optimization is The Most Important
Thing In The World, you probably need to re-implement R2
even if the new machine has the same instruction set as
the old. So it's not a question of implementing R1 vs.
R2, but a question of implementing R1 vs. all of R2a (for
Pentium IV), R2b (Xeon), R2c (Opteron), R2d (Power4),
R2e (Power5), R2f (UltraSPARC-IIIi), R2g (UltraSPARC-IV),
R2h (UltraSPARC-IV+), R2i (UltraSPARC-T1 "Niagara"), ...

Second, you must assess the likely benefits. "R2 is
faster" is not a strong enough statement; you need to know
how much faster it will be and balance that against the
extra effort required to develop and maintain it. The
question of how many times Rx will be used comes into this
assessment: I put it to you that it is of *no* use at all
to save ten nanoseconds per abort() call! (If you spend
just one minute inventing, implementing, documenting, and
testing a ten-nanosecond improvement to abort(), you will
not recoup your effort until *six billion* programs have
died horrible deaths.)

Third, there's the phenomenon that "clever" code is
more attractive to bugs than is simple code. It is easier
to see and remove a problem from the neatly-trimmed lawn
of a stretch of simple code than when it's camouflaged amid
the high grass, thorn thickets, and meandering waterways
of the wild Everglades. [Insert comment about "up to one's
rear in reptiles" here.] Even if tricksy code starts life
bug-free, it is more susceptible to acquiring bugs later on
as programmers who understand it imperfectly (and don't
realize the lack) "improve" the code to meet new requirements.
Those programmers are not some inferior subspecies of half-
wits, either: They are likely to be YOU. I believe it was
Kernighan who observed that debugging code is harder than
writing it; it follows that if you write it at the limits
of your own cleverness, it will be beyond your power to fix.

Fourth and finally, let's be clear about what kinds of
"optimization" we're considering. Replacing bubblesort with
Shellsort is not an "optimization," but a redesign using a
superior algorithm. Finding a way to re-use some of the work
of iteration N so that iteration N+1 needn't recalculate it
is a similar transformation. Changes in algorithm, changes
in data structure -- these are "finding better solution
methods," not "optimizations." The specific substitution
that sparked this sub-thread had to do with copying data
via a loop in open code instead of using memcpy(), based on
an untested assumption that the open code loop would be
faster -- that sort of thing is an "optimization" or (for
clarity) a "micro-optimization," and that sort of thing is
folly if done without measurement and a clear understanding
of the (supposed) benefits.

The days of Mel are behind us. The economics that made
his heroics worth while are gone, in fact, inverted: CPU
time became cheaper than programmer time long ago. Practices
that were once essential to success have become irrelevant,
replaced by newer practices that would not have made sense in
the world as it once was. If you act as if you were still in
that world you are dreaming; wake up and smell the gigahertz!

--
Er*********@sun.com

[Flash Gordon]

Andrew Poelstra wrote:

On 2006-07-26, av <[e-mail]:

>On Wed, 26 Jul 2006 12:19:13 +0100, Flash Gordon wrote:

>>av wrote:
On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:
Robbie Hatley wrote:
>[...]
"Premature optimization is the root of all evil."
-- D.E. Knuth
don't know

"We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson
these rules are wrong
What makes you think that you know better than well respected experts?

i find a lot of fun searching for optimisation code (and algorithm)
and until now not have wrong experiences
i would translate my c files in assembly and i'm sure in the
translated files, instructions will be between 1/10 and 1/100 than C
files, but the cpu has enough cache for the code and i'm lazy

Set the compiler to its maximum optimization level, and see whether or
not you're smarter than it.

And use a modern compiler. Compiler optimisation has moved on a lot in
the last 20 years.

>>One is in general far more likely to achieve significant improvements be
selecting the correct algorithm and design. Only when those are optimal,
and if there is still a demonstrable problem, should one use
measurements to find the problem areas and optimise them.

one good idea is better that all the optimal-ways walk

This is a typical sentence of yours: please use proper grammar and
punctuation, and try to make your sentences more coherant (if you
don't speak English natively, this will be harder than the others).
As it stands, I have no idea what you just said.

Agreed. We can cope with bad English to a degree, but av is extremely
hard to understand.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Keith Thompson]

av <[e-mail]:

On Wed, 26 Jul 2006 13:39:24 +0100, Chris Dollin wrote:

>>av wrote:

>>> "We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

these rules are wrong

Why do you think that?

Address what needs to be addressed when it needs to be addressed.

("Not optimising" doesn't mean "write stupidly slow code".)

i have a routine R1 that with input A has output B that follow the
algo C.
optimisation is
search a routine R2 that with input A has output B that follow an algo
H that has minimum instructions for doing calculation

are we agreeing on that definition?

why i would not try to write the "H" routine?
in my little experience errors could be in R1 too ...
and think on that routine can make to see errors in R1 too

The rules of optimization, quoted above, refer mostly to source-level
micro-optimization, things like adding "register" keywords and
manually unrolling loops. These are things that should be avoided
unless (a) you really know what you're doing, and (b) it significantly
and *measurably* helps performance. Without those conditions, you're
just as likely to make the code more difficult to read and maintain
for the sake of an optimization that the compiler could have done for
you.

On the other hand, choosing the best high-level algorithm for a task
is perfectly reasonable. For example, using a quicksort or mergesort
rather than a bubblesort is perfectly reasonable. Tweaking the inner
loop of a bubblesort so it runs 20% faster almost certainly is not.

Write clear code, with an emphasis on making it obvious what you're
doing rather than how you're doing it. If it works correctly and is
fast enough, you're done. If not, *then* you might consider
source-level micro-optimization if all other approaches have failed.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[av]

On Wed, 26 Jul 2006 16:45:48 GMT, Andrew Poelstra wrote:

>On 2006-07-26, av <[e-mail]:

>On Tue, 25 Jul 2006 07:58:19 GMT, Robbie Hatley wrote:

>>>"Richard Riley" wrote:
"Robbie Hatley" <bo***********@no.spamwrites:

Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies:
while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???
Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
either increment occurs???

Yes.

Thanks.

Same as in C++ when dealing with char pointers isnt it?

If it works that way with the one, I suppose it does with the
other. However, my usual way of coping strings in C++ is:

std::string str1 ("Fred"); // make string str1 containing "Fred"
std::string str2 (str1); // make string str2 and copy str1 to str2

A bit simpler than in C. :-)

in c++ all can be more simple and secure than c

Hardly. In C you can see exactly what's happening. No black boxes, hidden
*this pointers, overridden functions, *shudder* passing by reference with
no discernable change in how you call it, and no *also shudder* overloaded
operators.

in borland c++ i can see what happen and in 100-150 routines until now
i have no problem in this direction
you sound like someone that has never tried ...

>That, and a monkey could read some manpages and figure out what any line
of C does (although he obviously would be unable to recreate that or
figure out /why/ each line does what it does. Monkeys aren't the brilliant
typists that people would like us to believe.) C++ has a plethora of new
concepts, keywords, styles, etc. Not everything is simpler in C++.

i don't use all; i choose what "work for me" and classes
distructors/constructors are good

>Finally, C itself is not insecure. Just because you're a bad programmer
(and a lazy typist) does not mean that you should switch to a language
where your inadequacies are hidden. It means that you should learn your
language well. Buffer overflows are easy to avoid ("Don't use gets()!"
will prevent 90% of them), as are pretty well all of the common pitfalls.

i not agree

[av]

On Wed, 26 Jul 2006 20:00:49 +0100, Flash Gordon wrote:

>Andrew Poelstra wrote:

>On 2006-07-26, av <[e-mail]:

>>On Wed, 26 Jul 2006 12:19:13 +0100, Flash Gordon wrote:
av wrote:
On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:
>Robbie Hatley wrote:

>Agreed. We can cope with bad English to a degree, but av is extremely
hard to understand.

if someone can correct where i wrong, i can say to him-her-it(the
automatic corrector) a big "thank you"

[av]

On Wed, 26 Jul 2006 15:17:50 -0400, Eric Sosman wrote:

>av wrote On 07/26/06 12:33,:

>On Wed, 26 Jul 2006 13:39:24 +0100, Chris Dollin wrote:

>>>av wrote:
"We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

these rules are wrong

Why do you think that?

Address what needs to be addressed when it needs to be addressed.

("Not optimising" doesn't mean "write stupidly slow code".)

i have a routine R1 that with input A has output B that follow the
algo C.
optimisation is
search a routine R2 that with input A has output B that follow an algo
H that has minimum instructions for doing calculation

are we agreeing on that definition?

why i would not try to write the "H" routine?

To begin with, things are seldom that simple. For
example, suppose you can implement R1 in portable C but
must use assembly language for R2. This means you need
to re-implement R2 every time you move to a new machine;
if you really think optimization is The Most Important
Thing In The World, you probably need to re-implement R2
even if the new machine has the same instruction set as
the old. So it's not a question of implementing R1 vs.
R2, but a question of implementing R1 vs. all of R2a (for
Pentium IV), R2b (Xeon), R2c (Opteron), R2d (Power4),
R2e (Power5), R2f (UltraSPARC-IIIi), R2g (UltraSPARC-IV),
R2h (UltraSPARC-IV+), R2i (UltraSPARC-T1 "Niagara"), ...

ok, if you have only one cpu

all software is not the same
the are the difficult part (routine for calculus and difficult algo)
that will be difficult in any language of programming
and have the need of much effort
for that software i think is better that who maintain it == who wrote
it

Second, you must assess the likely benefits. "R2 is
faster" is not a strong enough statement; you need to know
how much faster it will be and balance that against the
extra effort required to develop and maintain it.

yes (for how you see the thing)

>The
question of how many times Rx will be used comes into this
assessment: I put it to you that it is of *no* use at all
to save ten nanoseconds per abort() call! (If you spend
just one minute inventing, implementing, documenting, and
testing a ten-nanosecond improvement to abort(), you will
not recoup your effort until *six billion* programs have
died horrible deaths.)

yes
....

>I believe it was
Kernighan who observed that debugging code is harder than
writing it; it follows that if you write it at the limits
of your own cleverness, it will be beyond your power to fix.

i have not meet such function until now
the problems i fear are not errors that show themselves but hidden
errors that show themselves one time over 1000000
there is the need of some way to trace them

Fourth and finally, let's be clear about what kinds of
"optimization" we're considering. Replacing bubblesort with
Shellsort is not an "optimization," but a redesign using a
superior algorithm. Finding a way to re-use some of the work
of iteration N so that iteration N+1 needn't recalculate it
is a similar transformation. Changes in algorithm, changes
in data structure -- these are "finding better solution
methods," not "optimizations."

so there is "optimizations" in rewrite a c routine in assembly because
1) the number of assembly instruction decrease in the assembly version
2) in the translation, 90% of times, i can see the problem in a
different way and so i change the data structure or the routines way
of doing something so i change the algorithm

all has its pro and contra

contra - i know sometime all this can improve on "nanoseconds" and the
code will be unmantenable because few know assembly

contra - for write all particulars of that routines there is the need
of much time

pro - there will be more time to think on it, there will be more ideas
in the mind, and in what i know bugs will be less in the assembly
version than in the C version

pro - if someone write in assembly he/she grow the ability in debug
area and all this allow to understand how all pc works and why
something [can] goes wrong

[Ian Collins]

av wrote:

On Wed, 26 Jul 2006 20:00:49 +0100, Flash Gordon wrote:

>>Andrew Poelstra wrote:

>>>On 2006-07-26, av <[e-mail]:

On Wed, 26 Jul 2006 12:19:13 +0100, Flash Gordon wrote:

>av wrote:
>
>>On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:
>>
>>>Robbie Hatley wrote:

>>Agreed. We can cope with bad English to a degree, but av is extremely
hard to understand.

if someone can correct where i wrong, i can say to him-her-it(the
automatic corrector) a big "thank you"

Correct capitalisation would be good start...

--
Ian Collins.

[Flash Gordon]

Ian Collins wrote:

av wrote:

>On Wed, 26 Jul 2006 20:00:49 +0100, Flash Gordon wrote:

>>Andrew Poelstra wrote:

On 2006-07-26, av <[e-mail]:

On Wed, 26 Jul 2006 12:19:13 +0100, Flash Gordon wrote:
>
>av wrote:
>>
>>On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:
>>>
>>>Robbie Hatley wrote:

>>Agreed. We can cope with bad English to a degree, but av is extremely
hard to understand.

if someone can correct where i wrong, i can say to him-her-it(the
automatic corrector) a big "thank you"

Correct capitalisation would be good start...

Fullstops between sentences are also essential. I just gave up on one of
av's messages because working out where one sentence ends and another
begins was too much like hard work.

I believe the av's native language is one which uses fullstops and
capitalisation, so English not being his/her first language is no excuse.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Keith Thompson]

Flash Gordon <sp**@flash-gordon.me.ukwrites:
[...]

Fullstops between sentences are also essential. I just gave up on one
of av's messages because working out where one sentence ends and
another begins was too much like hard work.

I believe the av's native language is one which uses fullstops and
capitalisation, so English not being his/her first language is no
excuse.

Some non-British readers, particularly non-native English speakers,
might not be aware that "fullstop" refers to the '.' character (more
commonly called "period" in American English).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

Flash Gordon <sp**@flash-gordon.me.ukwrites:
[...]

>I believe the av's native language is one which uses fullstops and
capitalisation, so English not being his/her first language is no
excuse.

Some non-British readers, particularly non-native English speakers,
might not be aware that "fullstop" refers to the '.' character (more
commonly called "period" in American English).

To be a little more precise, the English name for '.' is "full stop", not
"fullstop".

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chris Dollin]

av wrote:

On Wed, 26 Jul 2006 13:39:24 +0100, Chris Dollin wrote:

>>av wrote:

>>> "We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

these rules are wrong

Why do you think that?

Address what needs to be addressed when it needs to be addressed.

("Not optimising" doesn't mean "write stupidly slow code".)

i have a routine R1 that with input A has output B that follow the
algo C.
optimisation is
search a routine R2 that with input A has output B that follow an algo
H that has minimum instructions for doing calculation

are we agreeing on that definition?

Sort of. Nearish. Along those lines. (People often say "optimisation"
and mean "improvement" or "dramatic improvement" rather than "can't
make it any faster".)

why i would not try to write the "H" routine?

EG:

Life is short and other things have priority.

H is not robust against requirement changes.

Making H take zero time would only improve overall performance
by 1%.

It isn't possible to write unit tests for H without destroying its
performance advantages.

The module containing R1 will anyway be thrown away next week
when the real data arrives.

H is very hard to understand. Likely someone else will break
it after you've changed projects.

H is subject to IP protection.

in my little experience errors could be in R1 too ...
and think on that routine can make to see errors in R1 too

If you want to work on making code better, as in less buggy,
work on making it better, not on making it faster.

--
Chris "TDD" Dollin
"Who do you serve, and who do you trust?" /Crusade/

[Philip Potter]

"Robbie Hatley" <bo***********@no.spamwrote in message
news:ar*******************@newssvr12.news.prodigy. com...

>
Eric Sosman wrote of my string copy experiments:

... it seems more than a little likely that you are
committing the sin of premature optimization.

If this was a large app for long-term use by many, being
built and maintained by a team, then perhaps that might be
true.

But it's actually a tiny hobby app which I wrote expressly
for the purpose of optimization experimentation.

By all means then, experiment. It is an interesting exercise to find out how
fast you can implement something.

But I hope you understand how useless such practices are in real code,
outside of system libraries (such as those that implement memcpy() ). Also
see the below caveat about how to measure improvements.

Until and unless you have MEASURED a performance problem
not hypothecated, not supposed, not "it stands to reason-ed"
until you have made MEASUREMENTS it is irresponsible folly to
micro-optimize.

It's already in a batch file like so:

clock
MyProgram
clock

So I can instantly see whether making a particular change
causes execution time to go up, go down, or stay about the
same.

Hypotheses must come first. Then experimentation to determine
whether your hypotheses are brilliance or bunk. That's the
scientific method.

That is indeed the scientific method. However, your experiment doesn't
measure what you think it measures, and so will lead you to false
conclusions.

Much of the time between the two calls to "clock" will be set-up before
running MyProgram (allocating memory, loading code into memory, initialising
data, changing memory protection setup) and clean-up afterwards
(deallocating memory &c). These can take variable amounts of time depending
on how busy the OS is, how much of your program is in cache already, and the
phase of the moon, and so the variations in setup and cleanup can be greater
than the time-change to the core of the program. This means that even if
your program is running faster, it can appear to run slower, or worse - if
it is running slower, it can appear to run faster.

It's much better to use a tool designed for the job, such as a profiler.

"Premature optimization is the root of all evil."
-- D.E. Knuth

No, I think religiosity (addiction to untested ideas) is the
cause of most evil (including many bad computer programs, and
also including most wars).

It's not an untested idea. It's based on years of collective experience.

"We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

That's stupid. Fear gains nothing. Say instead:
1. If you see an opportunity to optimze, do it, as long as it
doesn't significantly damage readibility or modularity.

You've already broken your own rule. The "optimization" you wrote was
sufficiently confusing that you had to ask c.l.c about it. memcpy() would
have been much more readable.

2. Test it.
3. If it didn't significantly improve performance, revert.

Amdahl's law: optimize the common case.

If you optimize code which executes rarely, you spend lots of time on steps
1,2 and 3 above for an optimization which doesn't gain you much *overall*
speedup. Programmer time is expensive.

Remember that you don't know what "the common case" is until you have
measured it using a profiler. If you hold off optimization until the program
is complete or near-complete, you have a much better idea of a) whether any
optimization is necessary, and b) if it is necessary, where it should be
targeted. Hence "Don't do it yet.".

In most cases, optimization won't be necessary at all - the code is good
enough. All that effort on your 3-step plan will have been wasted.

In other words, I'm not the only person crying that ab initio
micro-optimization is folly; smart people do so, too. Be smart.

False reasoning. Imitating superficial aspects of the behavior
of smart people will not make one smart.

Ignoring smart people does not make one smart either.

And while it is perhaps true that most programs should not be
"optimized ab inito", some should be.

Yes. One example of code which should be "optimized ab inito" is that used
in system libraries, like implementations of memcpy(). If you are truly
interested in optimization, I suggest you learn about how memcpy() is
implemented on various machines. It's very interesting, and a good example
of why such optimizations should be restricted to library code.

Philip

[Andrew Poelstra]

On 2006-07-27, av <[e-mail]:

On Wed, 26 Jul 2006 16:45:48 GMT, Andrew Poelstra wrote:

>>On 2006-07-26, av <[e-mail]:

>>On Tue, 25 Jul 2006 07:58:19 GMT, Robbie Hatley wrote:
"Richard Riley" wrote:
"Robbie Hatley" <bo***********@no.spamwrites:
>
Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies:
while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???
Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
either increment occurs???
>
Yes.

Thanks.

Same as in C++ when dealing with char pointers isnt it?

If it works that way with the one, I suppose it does with the
other. However, my usual way of coping strings in C++ is:

std::string str1 ("Fred"); // make string str1 containing "Fred"
std::string str2 (str1); // make string str2 and copy str1 to str2

A bit simpler than in C. :-)

in c++ all can be more simple and secure than c

Hardly. In C you can see exactly what's happening. No black boxes, hidden
*this pointers, overridden functions, *shudder* passing by reference with
no discernable change in how you call it, and no *also shudder* overloaded
operators.

in borland c++ i can see what happen and in 100-150 routines until now
i have no problem in this direction
you sound like someone that has never tried ...

I have tried; the fact that << can mean absolutely anything one wants when
applied to an object caused me to revert to a language where thinks are
easy to understand at first blush.

>>Finally, C itself is not insecure. Just because you're a bad programmer
(and a lazy typist) does not mean that you should switch to a language
where your inadequacies are hidden. It means that you should learn your
language well. Buffer overflows are easy to avoid ("Don't use gets()!"
will prevent 90% of them), as are pretty well all of the common pitfalls.

i not agree

You're entitled to your opinion.

--
Andrew Poelstra <website down>
To reach my email, use <email also down>
New server ETA: 1 days

[av]

On Thu, 27 Jul 2006 19:23:45 GMT, Andrew Poelstra wrote:

>On 2006-07-27, av <[e-mail]:

>On Wed, 26 Jul 2006 16:45:48 GMT, Andrew Poelstra wrote:

>>>On 2006-07-26, av <[e-mail]:
On Tue, 25 Jul 2006 07:58:19 GMT, Robbie Hatley wrote:
>"Richard Riley" wrote:
>"Robbie Hatley" <bo***********@no.spamwrites:
>>
Hardly. In C you can see exactly what's happening. No black boxes, hidden
*this pointers, overridden functions, *shudder* passing by reference with
no discernable change in how you call it, and no *also shudder* overloaded
operators.

in borland c++ i can see what happen and in 100-150 routines until now
i have no problem in this direction
you sound like someone that has never tried ...

I have tried; the fact that << can mean absolutely anything one wants when
applied to an object caused me to revert to a language where thinks are
easy to understand at first blush.

you can use the debug and see what happen; there is no problem if you
know assembly; the hard work of place the small string "a<<b" with the
right function name
"this_could_be_the_lenght_of_name_that_<<_can_call _in_c++(a, b)"
is done from compiler (checking if type are ok too)
and i not have the need of type all that name

[Andrew Poelstra]

On 2006-07-29, av <[e-mail]:

On Thu, 27 Jul 2006 19:23:45 GMT, Andrew Poelstra wrote:

>>I have tried; the fact that << can mean absolutely anything one wants when
applied to an object caused me to revert to a language where thinks are
easy to understand at first blush.

you can use the debug and see what happen; there is no problem if you
know assembly; the hard work of place the small string "a<<b" with the
right function name
"this_could_be_the_lenght_of_name_that_<<_can_call _in_c++(a, b)"
is done from compiler (checking if type are ok too)
and i not have the need of type all that name

So, I should learn the assembly language of every system that I'm ever going
to use?

--
Andrew Poelstra <website down>
To reach my email, use <email also down>
New server ETA: 42

[ena8t8si]

Richard Heathfield wrote:

Robbie Hatley said:

Hello, group. I've been doing too much C++ programming lately, and
I'm starting to become rusty at some aspects of the C way of doing
things, esp. efficient low-level data copies.

Specificially, I just wrote the following, but I don't know if this
is safe:

It isn't, but perhaps not for the reason you imagine.

void Func(char* left, char* right)
{
chat temp_left [17] = {'\0'};
chat temp_right [17] = {'\0'};
int i;
char *ptr1, *ptr2;

/* ... do some stuff ... */

/* Copy the left part to temp_left: */
ptr1 = temp_left;
ptr2 = left;
while (ptr2 < right)

This comparison compares the ptr2 pointer value with a pointer to a
completely different object. Bad idea, unless you know for sure (and how
can you?) that 'right' is actually a pointer into the same object that
'left' points to.

*ptr1++ = *ptr2++; // WILL THIS WORK???

Yes, because ptr1 and ptr2 do not at any time point to the same char.

Even if they did point to the same char, the behavior
would still be defined.

[Richard Heathfield]

en******@yahoo.com said:

>
Richard Heathfield wrote:

>Robbie Hatley said:

<snip>

>>

*ptr1++ = *ptr2++; // WILL THIS WORK???

Yes, because ptr1 and ptr2 do not at any time point to the same char.

Even if they did point to the same char, the behavior
would still be defined.

Yes, on reflection of course you're right.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)