Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!husc6!yale!mfci!colwell From: colwell@mfci.UUCP (Robert Colwell) Newsgroups: comp.arch Subject: Re: String lengths Message-ID: <637@m3.mfci.UUCP> Date: 7 Feb 89 13:45:02 GMT References: <8876@alice.UUCP> <765@atanasoff.cs.iastate.edu> Sender: colwell@mfci.UUCP Reply-To: colwell@mfci.UUCP (Robert Colwell) Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 33 In article <765@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu (John Hascall) writes: =In article <8876@alice.UUCP= dmr@alice.UUCP writes: ==The question arose: why does C use a terminating character for ==strings instead of a count? ==In my opinion, C's array/pointer scheme for representation ==of character strings has worked out reasonably well, although ==it is somewhat clumsy when there are lots of string operations. = ==I don't think it has been demonstrated that the usual run of ==C programs pays an extremely high cost in performance for their ==string operations, though doubtless there are counterexamples ==for particular machine architectures or particular programs. = = This is a rather circular argument. This is rather like = saying "I don't think it has been demonstrated that the usual = automobile pays an extremely high cost in performance for their = amphibious operations,..." = = Just like most people don't drive their cars across lakes, = most C programs are not string operation intensive. Dennis's comment *could* have been circular, but I don't think it was. After all, the Unix OS has lots of places where exceptionally poor string handling would be obvious very quickly, and there are several known installations of this OS nowadays...On the other hand, there's Dhrystone -- if your string handling is poor, your Dhrystone number may well be pathetic. And Dhrystone is supposed to be a systems code benchmark (at least to this level of fidelity). Bob Colwell ..!uunet!mfci!colwell Multiflow Computer or colwell@multiflow.com 175 N. Main St. Branford, CT 06405 203-488-6090