Double increment question.

[Chris Dollin]

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.

 

[Andrew Poelstra]

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.

i not agree

You're entitled to your opinion.

 

[av]

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]

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?

 

[ena8t8si]

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]

(e-mail address removed) said:

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

Yes, on reflection of course you're right.