Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.lang.c
Subject: STREQ
Message-ID: <8277@utzoo.UUCP>
Date: Wed, 8-Jul-87 12:42:42 EDT
Article-I.D.: utzoo.8277
Posted: Wed Jul  8 12:42:42 1987
Date-Received: Wed, 8-Jul-87 12:42:42 EDT
References: <8011@brl-adm.ARPA>, <1711@umn-cs.UUCP>
Organization: U of Toronto Zoology
Lines: 25

> >>#define    STREQ(a, b)    (*(a) == *(b) && strcmp((a), (b)) == 0)
> 
>   This will also greatly slow a good many programs down on machines
> that do not support byte addressing.

No, not really.  Think about it:  all the macro is doing is duplicating
the first test that strcmp has to do.  Strcmp has to do it anyway, and
will probably have to do it much the same way.  (There are tricks that
can be used to do some string operations a word at a time, but they fall
down badly when the two strings are not aligned the same way -- a frequent
occurrence.)  Like most things, it is a tradeoff:  one redundant test in
the case of similar strings, versus one less function call in the case of
dissimilar strings.  Even on machines that have trouble with byte addressing,
a character comparison is likely to be considerably cheaper than a function
call.  STREQ loses only if similar strings (similar in the first character,
anyway) are considerably more common than dissimilar ones.  Empirically, in
most programs most strings are dissimilar, so STREQ wins on almost any
machine.

(Even disregarding this, using STREQ rather than direct strcmp wins big
everywhere, because it gives you the ability to change your mind about such
things by changing one macro definition!)
-- 
Mars must wait -- we have un-         Henry Spencer @ U of Toronto Zoology
finished business on the Moon.     {allegra,ihnp4,decvax,pyramid}!utzoo!henry