Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!uniwa!DIALix!metapro!bernie From: bernie@metapro.DIALix.oz.au (Bernd Felsche) Newsgroups: comp.sys.amiga.programmer Subject: Re: C string library? Keywords: strings, C Message-ID: <1991Feb25.101332.7433@metapro.DIALix.oz.au> Date: 25 Feb 91 10:13:32 GMT References: <874@cbmger.UUCP> <1991Feb15.050640.15436@metapro.DIALix.oz.au> <900@cbmger.UUCP> Organization: MetaPro Systems, Perth, Western Australia Lines: 51 In <900@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1991Feb15.050640.15436@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes: >>This is what I use under UNIX, though it should work under AmigaDOS as >>well. It doesn't do any garbage collection, but it's fast! Also, there >>is no mechanism to grow a string, though that should be a bit easier >>to implement (for somebody else :-)). >> >>It works by having a linked list pointing to a cluster of malloc'd >>memory chunks, the size of which can be "defined" at the start. >Thanks for the code, I'll look into it. Well, being lazy, I already >thought about something similar, but the management of all those >linked lists together with string growing plus garbage collection >really frightens me. Now: Not that I'm really motivated to do it right now, but; the freeing up and garbage collection routines can be handled by adding new (fake) space headers, and coalescing these when appropriate. This is easier said than done, unless you're drunk :-) Regarding your pointer-angst; it's really not _that_ hard. Besides, it's only ONE linked list of headers. You can add a new free header list, or tag it on the end of the others. >How about an approach similar to the one AmigaBasic takes it? [stuff about AmigaBasic and others zapped] Yuk.... A MicroSloth product! Wash your mouth out! :-) This can be almost as complicated, if not more complicated. You will notice that my code pre-allocates chunks of memory, the size of which can be selected at compile time. The reason for this approach is that a minimum of memory is pre-allocated, leaving as much as (reasonably) possible, for other processes. The mechanism for "growing" strings in the schemes you mentioned would be just as complicated, virtually independent of how memory is pre-allocated. (As far as I can tell.) Garbage collection might be simpler. Pointers to strings are stored in variables, in the calling routines. There is no need to store them in the allocated space. I'm still thinking about it, though. Certainly worth a closer look. All ideas gratefully accepted, as long as they're free. -- Bernd Felsche, _--_|\ #include Metapro Systems, / sale \ Fax: +61 9 472 3337 328 Albany Highway, \_.--._/ Phone: +61 9 362 9355 Victoria Park, Western Australia v Email: bernie@metapro.DIALix.oz.au