Re: beta testing

[Hans Aberg]

At 19:54 +0100 2001/02/20, Philippe Bekaert wrote:
>Does anyone however see a similar, simple, construction to avoid the
>global declarations of yychar ... and the forward declaration of
>yyparse() (when compiling with gcc)?
>
>A pure parser isn't going to help me in my particular case: I have other
>routines besides yyparse() that need access to these global variables.

If you check the code in bison.simple, it looks like

#if !YYPURE
YY_DECL_VARIABLES
#endif  /* !YYPURE */

#ifdef __cplusplus
int yyparse(YYPARSE_PARAM_ARG); // Prototype.
#endif
int
yyparse (YYPARSE_PARAM_ARG)
     YYPARSE_PARAM_DECL
{
  /* If reentrant, generate the variables here. */
#if YYPURE
  YY_DECL_VARIABLES
#endif  /* !YYPURE */
#if !YYPURE
YY_DECL_VARIABLES
#endif  /* !YYPURE */

#ifdef __cplusplus
int yyparse(YYPARSE_PARAM_ARG); // Prototype.
#endif
int
yyparse (YYPARSE_PARAM_ARG)
     YYPARSE_PARAM_DECL
{
  /* If reentrant, generate the variables here. */
#if YYPURE
  YY_DECL_VARIABLES
#endif  /* !YYPURE */
...

Thus, a pure parser only has local variables (or should only have it, I think).

For C++, there are two version though that comes to my mind: yyparse is
impure but its external variables are local to the class, and where yyparse
itself is pure, and thus all variables local to yyparse.

The first version suffices as a thread-safe version, if one only makes sure
there are no two instantiations of yyparse on the _same_ parse object.
Thus, write
  Parse p1, p2;
  p1.parse(); first invocation of yyparse
  p2.parse(); second invocation of yyparse

-- Thus, for C++, some data may end up in the class declaration, and other
in its definition. Some of it may then be user data (or methods), and one
problem is how the user should get that data into the class declaration, if
it say is going to happen via the .y file.

  One may have to divide the first %{ ... %} into two sections, where the
first section writes it into the class declaration.

  Hans Aberg