Re: Internal Representation of Strings

"Tony" <tony@my.net>
Wed, 25 Feb 2009 00:05:09 -0600

          From comp.compilers

Related articles
[25 earlier articles]
Re: Internal Representation of Strings scooter.phd@gmail.com (Scott Michel) (2009-02-22)
Re: Internal Representation of Strings cr88192@hotmail.com (cr88192) (2009-02-23)
Re: Internal Representation of Strings marcov@stack.nl (Marco van de Voort) (2009-02-23)
Re: Internal Representation of Strings haberg_20080406@math.su.se (Hans Aberg) (2009-02-23)
Re: Internal Representation of Strings tony@my.net (Tony) (2009-02-24)
Re: Internal Representation of Strings DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-02-24)
Re: Internal Representation of Strings tony@my.net (Tony) (2009-02-25)
Re: Internal Representation of Strings armelasselin@hotmail.com (Armel) (2009-02-26)
Re: Internal Representation of Strings marcov@stack.nl (Marco van de Voort) (2009-02-27)
Re: Internal Representation of Strings tony@my.net (Tony) (2009-02-28)
Re: Internal Representation of Strings cr88192@hotmail.com (cr88192) (2009-03-03)
Re: Internal Representation of Strings armelasselin@hotmail.com (Armel) (2009-03-02)
Re: Internal Representation of Strings tony@my.net (Tony) (2009-03-03)
[2 later articles]
| List of all articles for this month |

From: "Tony" <tony@my.net>
Newsgroups: comp.compilers
Date: Wed, 25 Feb 2009 00:05:09 -0600
Organization: at&t http://my.att.net/
References: 09-02-051 09-02-068 09-02-078 09-02-120
Keywords: storage
Posted-Date: 25 Feb 2009 14:27:47 EST

"Tony" <tony@my.net> wrote in message news:09-02-120@comp.compilers...
> "Chris F Clark" <cfc@shell01.TheWorld.com> wrote:
>
>> [For a well thought out design which keeps both the current and
>> allocated string sizes, see Bruce Guenter's bglibs,
>> http://untroubled.org/bglibs/docs/group__str.html -John]
>
> After looking at the definition of the str struct, I see this package
> won't
> be helpful for internal representation at the lowest levels though because
> the lengths are stored in a different area of memory than the character
> data. I'm trying to keep it so that going from disk to memory to the
> network requires no transformation.
>
> Tony
> [I don't think you're likely to find a format that is equally satisfactory
> in memory and on disk. -John]


Simply a length and the character data immediately following, probably.
Reallocation in memory is going to have to be done for dynamic strings of
course/maybe depending on the application. I think that will be where I'll
start and with a 32-bit length. Then if it shows to have a null terminator
on there to pass to 3rd party libs, I'll add that functionality. If the
overhead of 32-bit length become a problem (not likely), maybe a specialized
construct. At a high (library only) level, my 3-pointer implementation works
well, and even scales automagically to bizarrely long string lenths on a
64-bit platform (but suffers from more overhead for shorter strings).


Tony


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.