Aaron Jackson wrote: > Thanks for the response.
You're welcome. > On Feb 11, 2008, at 5:03 AM, [EMAIL PROTECTED] wrote: > >> To the best of my knowledge, you would need to modify the skeleton file. [...] > I wanted to avoid this since I want my .y code to be portable. It would be. You'd just have to include it in your distribution and account for this in your `make' rules and/or explain to users anything special they'd need to do. To the best of my knowledge, Bison uses to m4 to copy the skeleton file and inserts the parser rules and the corresponding actions in the appropriate places. However, I don't think it's necessary or desirable in this case. (I've never modified the skeleton file myself.) > 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. I didn't know about Bison's internal functions, which Joel Denny explained in his message, making it impossible, or at least impracticable, for users to declare local variables in `yyparse'. >From the point of view of programming philosophy, I don't see anything not clean about using the parameter. The place where you store your values is just a region of memory. I don't see any significant difference between letting it be popped from the stack when `yyparse' returns to its caller or freeing it after it returns. It will probably be cheaper to let it be popped from the stack, but not so much that I would choose to program in a way that would be less clear and understandable. If you're really worried about the caller of `yyparse' having access to the contents of the object passed as a parameter, you could use C++ and make them private data members. You wouldn't necessarily have to generate a C++ parser. I generate a C parser and compile with g++. On the other hand, if you're using C, you're already using a language that doesn't support data hiding that much anyway, so I wouldn't worry too much about it. After all, the caller of `yyparse' isn't going to access this data by itself --- it's under your control. (I'm not very "object-oriented".) It can also be very useful to have a structure that represents the state of a parse and which continues to exist after `yyparse' has returned. Laurence _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison