Gary Barnett <gbarnett@POLARNET.COM> writes:
> The buffer system is all well and fine, I didn't have any difficulty
> determining how it works or how to get it functional.
>
> However, it has become time to add all the release_buffer calls and with
> 2798 get_buffer calls I find myself dreading the prospect. I cannot do them
> a little at a time, as I can't place into production a mud that uses 180megs
> of ram at startup before the buffers time out and it settles down to 10 megs
> (which is a nice reduction from before I started adding the buffer system.)
There is an option for glibc based systems -- alloca. It's like
malloc except when used, the system will automatically free the memory
allocated. So...
#define get_buffer(n) alloca(n * sizeof(char) + 2)
char *s = get_buffer(MAX_INPUT_LENGTH);
You don't have to worry about free()ing the string because the alloca
takes care of that when the function that uses it returns.
Downside: MSVC++ people are probably out of luck. But it would be
possible to code it for arbitraty compilers using a tiny amount of
system depentant info (ie keeping track of the stack pointer, freeing
strings that are above you in the stack). Dunno if it's worh it... not
something I personally would worry on, but I don't use Windowsmachines.
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerjh/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST