Re: Internal Representation of Strings

"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

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