home *** CD-ROM | disk | FTP | other *** search
/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / usenet / altsrcs / 1 / 1903 < prev    next >
Encoding:
Internet Message Format  |  1990-12-28  |  1.3 KB
  1. From: falk@peregrine.Sun.COM (Ed Falk)
  2. Newsgroups: alt.sources
  3. Subject: Re: Fast strcmp() wanted.
  4. Message-ID: <1145@exodus.Eng.Sun.COM>
  5. Date: 4 Oct 90 21:03:47 GMT
  6.  
  7. In article <6003@hplabsz.HPL.HP.COM> sartin@hplabs.hp.com (Rob Sartin) writes:
  8. >In article <CEDMAN.90Sep29091115@lynx.ps.uci.edu> cedman@lynx.ps.uci.edu (Carl Edman) writes:
  9. >>string structure (or better class, long live C++ ! :-) which calculates
  10. >>a 32-bit CRC for each string the first time and stores it somewhere.
  11. >>Then only 1 (inlined) longword-compare will do the stringcomparisons
  12. >>for you.
  13. >
  14. >Afraid not.  It'll give you an estimate of whether the strings match
  15. >(correctly identifying those that don't).  You will need to then
  16. >actually compare the strings if they are the same.  This method will
  17. >also be unable to reproduce strcmp's behavior (strcmp returns a signed
  18. >result indicated the <, =, > by being negative, zero, positive), it will
  19. >only return a boolean (match, no match).
  20.  
  21. Also, these two strings
  22.  
  23.     "ab\0x"
  24.     "ab\0y"
  25.  
  26. (where x and y are any garbage that happens to be in memory after the
  27. terminating '\0') will be evaluated as unequal.
  28.  
  29. There are workarounds for both problems, of course, but I think there
  30. won't be much of a performance improvement after you've done all it
  31. requires to get it right.
  32.  
  33.         -ed falk, sun microsystems
  34.          sun!falk, falk@sun.com
  35.          card-carrying ACLU member.
  36.