Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!samsung!sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!rutgers!cbmvax!cbmehq!cbmger!peterk
From: peterk@cbmger.UUCP (Peter Kittel GERMANY)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: C string library?
Keywords: strings, C
Message-ID: <900@cbmger.UUCP>
Date: 18 Feb 91 11:04:34 GMT
References: <874@cbmger.UUCP> <1991Feb15.050640.15436@metapro.DIALix.oz.au>
Reply-To: peterk@cbmger.UUCP (Peter Kittel GERMANY)
Organization: Commodore Bueromaschinen GmbH, West Germany
Lines: 50

In article <1991Feb15.050640.15436@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes:
>In <874@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>
>>Now it should be possible to have a set of functions which initialize
>>a memory area and allocate dynamically all my strings in that space
>>just as a Basic interpreter does. Plus a good and fast garbage collection.
>
>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:

How about an approach similar to the one AmigaBasic takes it?
It has one heap space like any Basic interpreter from the old days.
This space is for prog + all variables, strings included. If you need
more space, you reserve some with the CLEAR statement. Now something
peculiar with this statement: It doesn't throw away the old space
and then allocates new one (it could, because it clears all variables
as the name implies), but first allocates the new area and only then
frees the old one. (So to get big chunks in tight memory situations
you have to use the trick to call it twice, once with the minimum
memory for your program (to free as much of system memory as possible),
and only then issue the real CLEAR statement.)

So I could do all this space reserving for my strings in a similar
manner: Initially reserve one big chunk of some arbitrary size, say
25 K, like in AmigaBasic. Like in an old Basic interpreter, store
your string pointers from the bottom of this area, the strings
themselves from the top. To speed up garbage collection, store a
back pointer into the pointer table with every string like in the
CBM 8032 Basic. Now when you run out of space, then allocate a
bigger chunk of memory in some arbitrary step, completely copy the
old area into the new one (you must do heavy pointer recalculations
then), and only thereafter free the old area. Well, this is not
extremely system and multitasking friendly and you risk to run out
of memory earlier, because you a) need it in contiguous chunks, and
b) need nearly twice the space temporarily, but it all appears much
easier to me. Any comments?

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk