Related articles |
---|
Yacc parsers: Cleaning up the wreckage! mch24@harvey27.demon.co.uk (1997-08-16) |
Re: Yacc parsers: Cleaning up the wreckage! dwight@pentasoft.com (Dwight VandenBerghe) (1997-08-19) |
Re: Yacc parsers: Cleaning up the wreckage! armbru@pond.sub.org (Markus Armbruster) (1997-08-20) |
Re: Yacc parsers: Cleaning up the wreckage! mch24@harvey27.demon.co.uk (1997-08-24) |
From: | Markus Armbruster <armbru@pond.sub.org> |
Newsgroups: | comp.compilers |
Date: | 20 Aug 1997 23:52:28 -0400 |
Organization: | Some lucky fish from Karlsruhe, Germany |
References: | 97-08-047 |
Keywords: | parse, yacc, errors |
mch24@harvey27.demon.co.uk (Martin Harvey) writes:
> However, the parser is bottom up, and as a result of the failure of
> rule e:_f then c,_f and S will not have been created and the parser
> will abort. This now means that I have a whole load of allocated
> objects on the parser stack, and no syntax tree at all :-(
>
> How on earth do I go about clearing up?? I suspect I need to comb
> through the parser stack finding all the parts of the syntax tree and
> deallocating them. However, this presents problems for me:
[...]
> What methods are there for picking up the pieces in situations like
> this??
[...]
> [Yacc isn't very helpful there, is it? I usually use my own malloc()
> wrapper than chains together the space it allocates so I can run down the
> chain and free everything after the parse completes one way or the other.
> -John]
Alternatively, have a look at Obstacks from GNU libc or at
@Article{Hanson:FAST-90,
author = {David R. Hanson},
title = {Fast allocation and deallocation of memory based on object lifetimes},
journal = {Software Practive and Experience},
year = 1990,
volume = 20,
number = 1,
month = Jan,
pages = 12
}
The basic idea is grouping objects with common life time together and
freeing them together. This simplifies programming and can be much
faster than calling malloc() and free() for every object.
Markus
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.