Re: Re[2]: bison %union and C++

[Hans Aberg]

At 16:37 +0200 2002/10/08, Akim Demaille wrote:
>| The most obvious thing under C++ is to not use %union or your Bison
>| destructors:
>
>*If* you are ready to pay a complete new hierarchy for this.

I see two typical uses of C++, one migrating from C, and another, writing
completely new C++ code.

As for Bison, these two approaches may require different treatments.

>| However, I did not find the type checking feature that essential, so I
>| stopped using it, instead using a single YYSTYPE C++ class:
>|   my_yystype {
>|     std::string text_;
>|     long number_;
>|     object object_; // C++ polymorphic variable.
>|   };
>
>Agreed, this is also what I recommend, but then you pay some extra
>space for each value.  But you still have not answered the question
>about leaking here: on successful error recovery, you will leak your
>text_.

Why would that leak?

-- I use a standard C++ container (std::list, std::vector or std::deque)
for my parser stacks. At the time of error recovery, the Bison generated
parser properly pops the stacks via container operations:
  yyerrpop:
    // Size 1 <-> stack in initial condition, so size 0 should not happen:
    if (YYSTACK_SIZE(yyss) <= 1)
      YYABORT;
    YYSTACK_POP(yyvs);
    YYSTACK_POP(yyss);
    yystate = YYSTACK_BACK(yyss);
  #if YYLSP_NEEDED
    YYSTACK_POP(yyls);
  #endif

When these stacks are popped, the C++ destructors are invoked.

>| >BTW, I'm not sure we can find a means to use try/catch to recover the
>| >memory thrown away during a successful error recovery.
>|
>| I am not sure why you think not:
...
>I mean that the parser have their error recovery scheme built as
>normal functioning.  It is not something that is to be interrupted.

This would be for exceptions that throws one out of the parser.

>Try to implement what you think, and I think you'll see what I mean.

I guess that one will have to sit down experimenting with the code,
preferably with a system good at discovering memory leaks (which I do not
have).

Also, I write full C++ code, including for the stacks then, so I do not
have any use of Bison's own destructor code.

  Hans Aberg