Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site utastro.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!eagle!harpo!seismo!ut-sally!utastro!nather From: nather@utastro.UUCP (Ed Nather) Newsgroups: net.lang.c Subject: Re: What Can't C Do? (strings) Message-ID: <58@utastro.UUCP> Date: Sun, 18-Mar-84 22:29:30 EST Article-I.D.: utastro.58 Posted: Sun Mar 18 22:29:30 1984 Date-Received: Tue, 20-Mar-84 00:38:21 EST References: <6900@unc.UUCP>, <226@opus.UUCP> Organization: UTexas Astronomy Dept., Austin, Texas Lines: 27 <> Discussions of string comparison usually start with two assumptions that I believe are false: 1. A language is deficient if it lacks string comparisons; 2. They *could* be included, at modest cost in complexity. In the various C programs I have written that involve string comparisons, I find the ability to call a function to do exactly the right thing a real convenience. Sometimes I want to compare a substring to a string both of which are null-terminated; next time the substring may not be. Sometimes I want the pointer updated to point to the first character that didn't compare, sometimes not. I may want the *second* appearance of a substring rather than the first or last. If every possible option were included as part of a language the cost in complexity would not be modest -- and I'd never remember all the options. Alternatively, if only the basic, vanilla comparisons are included, it won't do what I want, I'll have to write a function call anyway, then explain in a comment why I had to do it that way, fuming all the while. After all this, an opinion: Leave the string comparisons OUT. -- Ed Nather ihnp4!{ut-sally,kpno}!utastro!nather Astronomy Dept., U. of Texas, Austin