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