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

[Akim Demaille]

| At 10:42 +0200 2002/09/30, Akim Demaille wrote:
| >AD> Using pointers to string. Or make sure to have a single hierarchy,
| >AD> which means that you must wrap std::string :(
| >Oleg> yeah, but every time bison removed something from the stack I
| >Oleg> get a memory leak. (which I have worked around by keeping track
| >Oleg> of what bison allocs and frees, but it's quite nasty)
| >
| >If you are ready to use a beta (and it will certainly change in the
| >future, so *this is a bad idea*), you can try this:
| >
| >%destructor { delete $$; } expr stmt etc...
| >%destructor { free ($$); } C_STRING
| 
| This will leak when using C++ exceptions:

Good call!

| Under C++, one usually must allow the exception handling stack unwinding
| see the objects whose resources should be destroyed.
| 
| It may happen can handle it by the use of a construct
|   try {
|     // Bison generated code.
|   } catch (...) {
|     // Bison destructor code
|     throw; // re-throw the exception.
|   }
| 
| Then any C++ exception out of the Bison parser will be able to execute
| resource deallocating before passing the exception on to the program
| calling the parser.
| 
| Some may use an "embedded C++" subset which does not admit C++ exceptions.
| So Bison should support that, then that try-catch construct above must be
| an option.

I agree in a perfect world that's the way things should probably be
done.  But in this very material world, for the time being, I'm afraid
we will just tell the user not to use exceptions.

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.