Related articles |
---|
[2 earlier articles] |
Re: Different string format options, benefits? pk@cs.tut.fi (1991-10-18) |
Re: Different string format options, benefits? agulbra@Siri.Unit.NO (1991-10-18) |
Re: Different string format options, benefits? db@dcs.ed.ac.uk (Dave Berry) (1991-10-20) |
Re: Different string format options, benefits? tm@well.sf.ca.us (1991-10-22) |
Re: Different string format options, benefits? buzzard@eng.umd.edu (1991-10-25) |
Re: Different string format options, benefits? henry@zoo.toronto.edu (1991-10-25) |
Re: Different string format options, benefits? sdm7g@aemsun.med.virginia.edu (1991-11-01) |
Re: Different string format options, benefits? bliss@sp64.csrd.uiuc.edu (1991-11-05) |
Newsgroups: | comp.compilers |
From: | sdm7g@aemsun.med.virginia.edu (Steven D. Majewski) |
Keywords: | C, optimize |
Organization: | University of Virginia - Physiology Dept. |
References: | 91-10-089 91-10-098 91-10-102 |
Date: | Fri, 1 Nov 91 17:05:31 GMT |
I believe Icon stores strings as (length-count,pointer-to-string-pool).
Substrings can point to parts of the same string and concatenation
*can* append to the end of an existing string (if there is free space),
yielding same pointer, different length counts.
( There is no attempt to find a match for a sub-string - it is only done
if the super-string is used in the expression that yields the sub-string:
e.g. S1 := "e.g. examples included" ; S2 := S1[6:13] )
I'm sure that other languages where expressions|functions can yield strings
do something similar. ( examples anyone? ) But I don't think it buys you
much in a C type language where strings are not a built-in data-type.
- Steve Majewski
Steven D. Majewski University of Virginia Physiology Dept.
sdm7g@Virginia.EDU Box 449 Health Sciences Center
Voice: (804)-982-0831 1600 Jefferson Park Avenue
FAX: (804)-982-1616 Charlottesville, VA 22908
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.