Re: Internal Representation of Strings

> 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.


this is a common implementation, which is rather cool when strings are
immutable or in Copy On Write (you need to add a reference count then along
the length).


> Then if it shows to have a null terminator
> on there to pass to 3rd party libs, I'll add that functionality.


this is indeed _very_ useful to keep a few zero bytes at the end, whenever
calling a C-like API, it avoids memory allocation/de-allocation and copy at
API call time... malloc/free are extremely time consuming (with respect to
simply putting a zero at the end of string), and this need for
temporary-zero-ended copy will clearly not be in the "I think of this as a
big task" when calling very simple APIs.


NB: I write above 'a few' because in my mind, it depends on encoding,
UTF-16/32 will need more than one zero byte. of course, dealing with
evertyhing in UTF8 is so simple.


HIH
Armel

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