Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c
Subject: Re: strings
Message-ID: <190@mole-end.UUCP>
Date: 14 May 89 06:35:15 GMT
References: <2846@tank.uchicago.edu> <5785@cbnews.ATT.COM> <10087@smoke.BRL.MIL> <10245@socslgw.csl.sony.JUNET>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 32

> >>C says that a string is terminated with a '\0' byte.  ...  C programmers
> >>assign a '\0' byte, so the implementation of C library routines can never
> >>be speeded up.  For other languages, [implementations are often improved].
 
> >Improvements to C library routines are quite possible.  Like all such,
> >cleverness is sometimes required.  ...
 
> How do you improve a C library routine to look in a string descriptor to
> just grab the current length of the string?  In other languages, libraries
> can do that.  ...

Or the compilers can emit code ...

> ...  It kind of seems to me that if a C library does that, [ it will ] break
> my legal C program.  On the other hand, [ strlen() ] has to scan every byte
> of ... my 300K ... or my 509-byte array ... several thousand times.  It seems
> intrinsically worse to me.

Well, in C you are stuck.  At the risk of being told to go to my own group,
this is the point where you should switch to C++ and define a string type
that uses whatever you have available in your particular environment.  Just
derive it (compatibly) from an existing string type so that if you have to
run in a pure-C++ environment, you have a fallback.   Oh, and where a compiler
would emit code, you can make C++ use inlines.

Of course, I could ask you to show me a machine on which the FORTRAN compiler
has access to the internal implementation of COBOL, or on which COBOL can be
made to use the FORTRAN complex arithmetic algorithms.  We could go on.
-- 

 (This man's opinions are his own.)
 From mole-end				Mark Terribile