Thanks for the response.
On Feb 11, 2008, at 5:03 AM, [EMAIL PROTECTED] wrote:
I would like to declare some variables that are local to yyparse.
To the best of my knowledge, you would need to modify the skeleton
file.
When I wanted to do this, I determined that it was not possible
otherwise.
I may be wrong, but I don't think this has changed with more recent
versions.
I wanted to avoid this since I want my .y code to be portable.
I
am building a linked list of structures, and I need to make sure I
have values for all the structure members before I add a new node to
the list. Since I wrote the parser to be a pure parser, global
variables, are not an option.
Why not? I'm not recommending this, but you can certainly declare
global
variables and make them accessible to `yyparse' in the ordinary way
(i.e.,
by using `extern' declarations, if necessary). If you're using
threads,
you will, of course, have to protect these variables with mutexes,
which
would reduce concurrency. That's why I recommend against doing this.
OK, I think I worded my email a bit too strong. I would prefer not
to use global variables for the reasons you mentioned.
Something like %initial-action {int x;
int y; int z;} doesn't work, since the initial action code is
enclosed in braces and the variables x,y,z,etc. do not exist outside
the braces. If I use %parse-param{variables_t variables;}, where
variables_t is a structure containing x,y,z, I get what I want, but
since I don't need x,y,z after yyparse returns, this seems like an
inefficient way to do things. Is there a better way to do this?
There must be a "standard" way this is done---temporarily saving all
the previously parsed values until all the required values are
available. Any help would be very appreciated. Thanks.
I recommend declaring a `struct' or `class' type for use as the
parameter
to `yyparse'. You can put anything you want into it, not just these
variables. If you're worried about the memory, you can declare this
object in such a way that it will be on the stack and disappear in the
fullness of time. Otherwise, you could allocate memory for it on
the heap
and free it when you're done with it. However, the cost of doing this
with respect to time might outweigh the real or imaginary advantage
of not
declaring it statically.
Unless you're working on a system where every clock cycle and every
byte
of memory counts, I wouldn't worry about a few integers, or even a few
larger objects.
I allocate the (very large) object that I pass as the parameter to
`yyparse' (and `yylex') on the heap and free the memory when I'm
done with
it.
I ended up using a structure with all the variables I needed, but it
just doesn't seem personally satisfying to me. It just seems cleaner
if I could declare variables that are local to yyparse, that way, the
function calling yyparse doesn't have to know what's going on in the
background.
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison