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

[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 "optimisati on"
and mean "improvemen t" 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/

[Andrew Poelstra]

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

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

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

>>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] e:

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

>>>On 2006-07-26, av <[e-mail] e:
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_n ame_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] e:

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_n ame_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)