Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!aramis.rutgers.edu!paul.rutgers.edu!jac
From: jac@paul.rutgers.edu (Jonathan A. Chandross)
Newsgroups: comp.lang.icon
Subject: Re: deleting characters
Message-ID: <Jan.21.22.24.44.1990.9958@paul.rutgers.edu>
Date: 22 Jan 90 03:24:46 GMT
References: <9001200111.AA16921@june.cs.washington.edu>
Distribution: inet
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 42


wgg@CS.WASHINGTON.EDU (William Griswold)
> Many common operations in Icon require *more* time to perform in C--using
> available abstractions--such as computing the length of a string.  Also
> note that string concatentation in C in the standard way (using strcat)
> takes linear time.  It also requires knowing the destination string is
> long enough to hold the longer result.  Thus making strip as ``fast'' as
> Icon's requires a little effort. 

I don't know if your statement is totally fair.  There is nothing to
prevent one from using BCPL style strings (i.e. also store a length
with the string) in a C program.

In fact, this is done.  The MESA language (XEROX) generates C code
which is then compiled normally.  Strings in MESA are stored with
a length, and are word aligned.  This allows strcpy, strcmp, et al
to work on word quantities,  producing much faster string routines. 
I see no reason (aside from inertia) for why this has not been done
to C.  (Well, one would have to write routines to convert from the
library function's notion of a character string to the new one with
a length.)

A while back I needed to derive the name from a file pointer.  Since
stdio does not support this I had to write a piece of code like:
	struct N_FILE {
		char	*name;
		FILE	*file;
		};
and the associated front-end routines for stdio.  This was not hard
to do, and did not take all that much time.

Of course, one could say that the pattern matching, associative
table features, etc. that make Icon so popular could also be added
to C using the argument I give above.  I won't (and can't) defend
such a statement.  My point is that condemning C for a shortcoming
in the library routines is not really fair.  Especially when that
problem could be fixed in a few days hacking.


Jonathan A. Chandross
Internet: jac@paul.rutgers.edu
UUCP: rutgers!paul.rutgers.edu!jac