String move Macro.

[vashwath]

Hi all,
Below macro moves specified number of bytes from a specified index of
source
string to a specified index of destination string.

#define STRMOV(src_str,src_ind,length,dst_str,dst_ind)\
do\
{\
int s,d;\
s = src_ind;\
d = dst_ind;\
while(s < length && src_str != '\0')\
{\
dst_str[d] = src_str;\
d++;\
s++;\
}\
}while(0);

I have tested this for some inputs. Looks like this is performing the
intended functionality.
Please let me know if there are any corrections or any improvements to
be done to this macro.

Thanks

 

[Vladimir Oka]

Hi all,
Below macro moves specified number of bytes from a specified index of
source string to a specified index of destination string.

#define STRMOV(src_str,src_ind,length,dst_str,dst_ind)\

It is not clear from this (or rather, it's misleading) or your
description above, that `length` refers to the length of source string,
and not the substring to copy. If you supply the "specified number of
bytes" nothing happens. If you use `strlen()` to supply the length,
compiler (at the paranoid warning level) complains about comaprison
betwee signed and unsigned values.

do\
{\
int s,d;\
s = src_ind;\
d = dst_ind;\

Why do you need both? You don't even use `d`.

while(s < length && src_str != '\0')\
{\
dst_str[d] = src_str;\
d++;\
s++;\
}\
}while(0);

I have tested this for some inputs. Looks like this is performing the
intended functionality.
Please let me know if there are any corrections or any improvements to
be done to this macro.

Make it a proper function.

What you think you gain in performance, you lose in safety,
readability, and maintainability. E.g. if you erroneously supply an
`int` as the source string (typos, typos), the error message is less
than useful:

main.c:27: error: subscripted value is neither array nor pointer
main.c:27: error: subscripted value is neither array nor pointer

Not to mention that the line the error points to is where the macro was
used, rather than the line inside the macro that failed.

As a function, you'd get free type compile time type checking of
parameters, and much, much more...

 

[Suman]

Hi all,
Below macro moves specified number of bytes from a specified index of
source
string to a specified index of destination string.

#define STRMOV(src_str,src_ind,length,dst_str,dst_ind)\
do\
{\
int s,d;\
s = src_ind;\
d = dst_ind;\
while(s < length && src_str != '\0')\
{\
dst_str[d] = src_str;\
d++;\
s++;\
}\
}while(0);

#include <string.h>

#define STRMOV(src_str,src_ind,length,dst_str,dst_ind) \
do {
strncpy( src_str[ src_ind ],
dst_str[ dst_ind ],
length );
} while( 0 )

.... or just strncpy(). Or are you not allowed to use strncpy ?

 

[vashwath]

#define STRMOV(src_str,src_ind,length,dst_str,dst_ind)\

The reason I am doing this is to improve execution speed(Requirement
from client). Currently I am using memcpy to achieve this. Now I am
planning to write my own Macro.

 

[Vladimir Oka]

The reason I am doing this is to improve execution speed(Requirement
from client). Currently I am using memcpy to achieve this. Now I am
planning to write my own Macro.

Have you followed the rules of optimisation:

1. Don't do it.
2. Don't do it, yet. (experts only)

Also, have you *measured* and found out that this is what kills your
performance. On the face of it, it doesn't sound as if it's going to
gain you much (apart from the headaches I mentioned elsethread).
Experience shows that algorithmic improvements tend to beat performance
tweaks.

 

[Richard Heathfield]

(e-mail address removed) said:

Hi all,
Below macro moves specified number of bytes from a specified index of
source
string to a specified index of destination string.

#define STRMOV(src_str,src_ind,length,dst_str,dst_ind)\
do\
{\
int s,d;\
s = src_ind;\
d = dst_ind;\
while(s < length && src_str != '\0')\
{\
dst_str[d] = src_str;\
d++;\
s++;\
}\
}while(0);

I have tested this for some inputs. Looks like this is performing the
intended functionality.
Please let me know if there are any corrections or any improvements to
be done to this macro.

The most obvious improvement would be to replace the macro with:

#define STRMOV(ss,si,len,ds,di) memmove(ds+di, ss+si, len)

and the second most obvious improvement would be to remove the macro
completely and just call memmove (or perhaps memcpy) directly.

 

[Richard Heathfield]

Vladimir Oka said:

Also, have you *measured* and found out that this is what kills your
performance. On the face of it, it doesn't sound as if it's going to
gain you much (apart from the headaches I mentioned elsethread).

On the contrary, it's quite likely to damage performance considerably, if he
is heaving very much data around in this way.

Experience shows that algorithmic improvements tend to beat performance
tweaks.

<aol>Indeed.</aol>

 

[Vladimir Oka]

Vladimir Oka said:


On the contrary, it's quite likely to damage performance considerably, if he
is heaving very much data around in this way.

My clipboard still contains this sentence, apparently lost in some
reshuffling of my original reply to OP: "I can't see that you gain any
performance at all for anything but the tinyest of substrings." There
were too many things wrong with OP, it seems.

<aol>Indeed.</aol>

<aol>?

 

[Richard Heathfield]

Vladimir Oka said:

My clipboard still contains this sentence, apparently lost in some
reshuffling of my original reply to OP: "I can't see that you gain any
performance at all for anything but the tinyest of substrings." There
were too many things wrong with OP, it seems.

Maybe - just *maybe* - he can outperform memcpy if his string is maybe two
or three bytes long. I doubt very much whether he could do four bytes as
quickly as memcpy can.

<aol>?

Oh, sorry - AOL subscribers were famous for posts that quoted an entire
article (maybe hundreds of lines) just so that they could add "I agree" to
it - sometimes at the bottom so that you scrolled all the tedious way down
before finding the non-information written there; one of those rare
occasions where bottom-posting actually made things (even) worse.

 

[Keith Thompson]

Richard Heathfield wrote: [...]

<aol>Indeed.</aol>

<aol>?

When AOL (America Online) first provided Usenet service to its
customers, it created a large influx of Usenet newbies. The canonical
AOL reply was a quotation of an entire article followed only by "Me
too."

 

[Keith Thompson]

#include <string.h>

#define STRMOV(src_str,src_ind,length,dst_str,dst_ind) \
do {
strncpy( src_str[ src_ind ],
dst_str[ dst_ind ],
length );
} while( 0 )

... or just strncpy(). Or are you not allowed to use strncpy ?

strncpy() doesn't necessary terminate the result with a '\0'. It's a
very specialized function that probably doesn't do what you think it
should do.

 

[Ian Collins]

The reason I am doing this is to improve execution speed(Requirement
from client). Currently I am using memcpy to achieve this. Now I am
planning to write my own Macro.

With a function of this small size, it should be inlined, so there isn't
any benefit form using a macro.

 

[Suman]

strncpy() doesn't necessary terminate the result with a '\0'. It's a
very specialized function that probably doesn't do what you think it
should do.

[1] The length parameter in the OP's macro is not well defined.
He says one thing & the code does another.

[2] The OP's macro hardly bothers about '\0'. Or did I miss something?

[3] Somewhere later in the thread he mentions using memcpy(): would
that be the function of choice were he to be so concerned with
'\0' ?

 

[Giannis Papadopoulos]

The reason I am doing this is to improve execution speed(Requirement
from client). Currently I am using memcpy to achieve this. Now I am
planning to write my own Macro.

If I am not mistaken, memcpy is there for a very good reason: it is
extremely fast, as it may use some OS-specific techniques to run much
faster than a simple for() or while().

--
one's freedom stops where others' begin

Giannis Papadopoulos
Computer and Communications Engineering dept. (CCED)
University of Thessaly
http://dop.freegr.net/

 

[pete]

Hi all,
Below macro moves specified number of bytes from a specified index of
source
string to a specified index of destination string.

#define STRMOV(src_str,src_ind,length,dst_str,dst_ind)\
do\
{\
int s,d;\
s = src_ind;\
d = dst_ind;\
while(s < length && src_str != '\0')\
{\
dst_str[d] = src_str;\
d++;\
s++;\
}\
}while(0);

I have tested this for some inputs. Looks like this is performing the
intended functionality.
Please let me know if there are any corrections or any improvements to
be done to this macro.

When your macro defines objects
and initializes them to the values of the macro arguments,
then your macro is halfway to being a function.
So why not go all the way, and write it as a function?

void str_mov(char *src_str, size_t s, size_t length,
char *dst_str, size_t d)
{
while(s < length && src_str != '\0') {
dst_str[d] = src_str;
d++;
s++;
}
}

 

[Al Balmer]

The reason I am doing this is to improve execution speed(Requirement
from client). Currently I am using memcpy to achieve this. Now I am
planning to write my own Macro.

Your own macro is almost certain to be slower.

MEASURE! You can't optimize without knowing where the time is taken.

 

[Walter Roberson]

If I am not mistaken, memcpy is there for a very good reason: it is
extremely fast, as it may use some OS-specific techniques to run much
faster than a simple for() or while().

strcpy() and strncpy() are part of the implementation and are
not required to be macros, so it is allowed for them too to use
"OS-specific techniques to run much faster than a simple for() or while()".
There isn't much of the standard C library which is required to
be implemented in pure C.