|Passing string literals in function calls in an interpreter firstname.lastname@example.org (2002-12-26)|
|Re: Passing string literals in function calls in an interpreter email@example.com (2002-12-30)|
|Re: Passing string literals in function calls in an interpreter firstname.lastname@example.org (2002-12-31)|
|From:||email@example.com (Roger Corman)|
|Date:||31 Dec 2002 00:01:15 -0500|
|Organization:||Prodigy Internet http://www.prodigy.com|
|Posted-Date:||31 Dec 2002 00:01:15 EST|
The alloca() solution is good--most C compilers seem to support
it. You have to be careful that the size of the literal strings is
small enough not to crowd your stack. If you happen to call foo("bar")
in a loop, it should reuse the same alloca'd buffer rather than
creating a new one each time. Typically each time it is called it
increases the stack frame size, and doesn't clean them up until you
exit the function.
This is where a garbage collector is really nice. You could write your
own simple one (although even a simple one can be complicated to get
right) or use something like the Boehm collector to have garbage
collection with C or C++.
On 26 Dec 2002 23:37:53 -0500, firstname.lastname@example.org (Dimitris) wrote:
>Hi, I'm writing a simple interpreter and, although it might sound
>stupid I'm having a little trouble with passing literal strings in
>function calls. ...
>[You're not the first to run into this problem. If your interpreter
>handles a statement at a time, I'd use a wrapped version of malloc
>that remembers all the space it allocated in a table or by linking
>the areas together, then free it all between statements. GCC and
>some other C compilers support a non-standard extension called alloca()
>that allocates space in the current routine's call stack, with the
>space being returned along with the rest of the local variables
>when the routine returns. -John]
Return to the
Search the comp.compilers archives again.