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

[Akim Demaille]

| 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.

| Then the C++ exceptions system will clean up the memory via normal C++
| calls destructors.
| 
| For a while, I used a variation of %union that I called %typed, which does
| all type checking that %union does, but does not require a C/C++ YYSTYPE
| union, plus some additional macros admitting one to do some polymorphic
| typecasting.
| 
| 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_.


| >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:
| 
| All that the C++ exception handler does is to call the C++ destructors of
| the destroyed objects in a suitable order, until returning the execution at
| a suitable catch point.
| 
| The object registered with your Bison cleanup system should be such that
| they are not seen by the C++ exception handler system (which happens if
| they are allocated with malloc or "new"). Then, when you arrive at the
| catch (...) above, there should be no problem merely invoking your Bison
| destructor: If the objects registered with it, they should not interfere
| with the C++ exception handling or vice versa.

I mean that the parser have their error recovery scheme built as
normal functioning.  It is not something that is to be interrupted.

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


| >%destructor { delete $$; } expr stmt etc...
| >%destructor { free ($$); } C_STRING
| 
| I guess that this assumes that you know what is on each entry in the stack,
| so that one can use the right destructor.

Errr...  of course...

| But what should the problem otherwise be?

Me no comprendo you.