Re: Internal Representation of Strings

"Armel" <armelasselin@hotmail.com> wrote in message
>> 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).


Are you suggesting that it may not be an appropriate implementation for
mutable strings and a library not using the COW technique?


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


(Aside: Note that when words or letters are missing from my posts it is
because my wireless keyboard sometimes drops out. Perhaps when it's
resynching or something. The above should have read: "Then if it shows
benefit to have a null terminator...).


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


My goal is to get away from all the APIs that use null-terminated strings,
so I will be replacing all of that. Not needing that null terminator would
be an indication of success of a string implementation that wished to depart
from that paradigm.


Tony

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