[LCP]wrapper around strcmp

[Vincent Penquerc'h]

> Definitely, I dont want my program to halt. Actually I myself 
> am not clear 
> about the usage of 'assert'. 'assert.h' has this macro,
> 
> #define assert(EX) (void)((EX)||(__assert(#EX, __FILE__, __LINE__),0))
> 
> I didnt understand this. Can you please say more on this?

Most probably, this bit was only defined within
#ifdef DEBUG
#endif
right ?
In non DEBUG builds, you will get something along the lines of:
#define assert(x) ((void)0)
or
#define assert(x) do {}while(0)

The point is that assert is only compiled in in DEBUG builds to
generate code that traps errors in the program. For instance,
checking that a char* is non NULL when it should not. These tests
are never included in non DEBUG builds, so don't slow the program
down.

About the definition of it, the particular one you have relies on
the short circuit evaluation of && and || in C. Since the || of
two expressions is true if either of its components is true, the
program will generate code that doesn't bother evaluating the
second one if the first one yields true. Therefore, code will
evaluate EX, and only call __assert (which probably abort()s or
sends a signal or something similar) if the first expression
actually yields false (as the truth value of the full expression
is then not known).
#EX is a construst which makes the compiler emit the string
representation of the expression you have, __FILE__ and __LINE__
are the textual file name and line number where the macro was
called (in the un-cpp'd original source file). __assert will
probably print those three strings to help you pinpoint what
exactly happened.

To get back to your first question, if you want speed, you might
want to create your own implementation of strings, which builds
on knolwedge you have of your strings, that the libc can't assume.
For instance, if you have only constant strings that you don't
add to, remove, or modify, you can make an array of these, and
pass around only the indices in the array of the strings. Comparing
two strings then boils down to integer comparisons. You can also
create a structure for each string which holds the string itself,
and a hash of it, so comparing the strings means comparing the
hash values. Of course, if you modify strings a lot and compare
not that much, it will be slower than plain strcmp.
Another solution is to make sure you only have dynamic strings
(eg malloc allocated, no string constants), and allocate by chunks
of 4 bytes (or whatever the word size is on your typical machine),
make sure you zero out the last ones (not only the ANSI zero
terminator), then do compares (a la strcmp) but using word compares
instead of char compares. OF course, you have to make sure you have
a full zeroed word, aligned, to be sure not to miss the ending null
for some string lengths. Bar cache misses, this should get roughly
4 times faster. It all depends on what you do, with what strings,
etc. Oh, I'm thinking of another possibility: store the length of
the string, and early out if the lengths are different.
There are plenty of solutions, really, when you know your data.

-- 
Vincent Penquerc'h 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux.org.au/pipermail/linuxcprogramming/attachments/20020523/bd17677e/attachment.htm