Re: A polymorphic YYSTYPE for C++ (instead of the %union)

[Hans Aberg]

On 16 Jun 2007, at 00:25, Michiel De Wilde wrote:

> > There is no change needed: I have used a standard C++ polymorphic  
> > class hierarchy for years
>
> I'm very interested. Could you provide an example grammar?

It does not have anything with the grammar as such to do: I use it to  
create a polymorphic class hierarchy, and then the grammar is used to  
create object for this class hierarchy. It is a theorem prover.

There is a "class object" which contains a polymorphic pointer to a  
virtual C++ hierarchy, also with a reference count acting as a GC.

> How do you
> use the safety-providing automatic type selection feature of Bison in
> this case (the equivalent of automatically choosing the right field of
> the %union)?

I do not use it, but I experimented once with a variation of %union  
that only triggers the typing mechanism, which I called %typed. The  
Bison typing mechanism merely selects a filed in the union based on  
the type name, so the idea is to replace this with a macro, as in C++  
one should use static_cast or dynamic_cast.

> > A typed replacement of %union: Then I think the problem is with  
> > the default actions, which no longer can be collected to a single  
> > entry in the parser "switch" statement.
>
> Very true. I've addressed this by outputting a muscle (in
> src/output.c) providing C++ code that is executed right before a
> reduction action.

This was originally out of the switch statement, but I think was  
moved into it (don't remember details), in order to avoid double  
execution of the default rule, which is OK in C, but not in C++,  
which may have special copy-constructors (like auto_ptr).

> It initializes the yyval variant to a
> default-constructed object of the right result type.

And a problem with variant is that it does not work with recursove  
data types. In addition, if one is writing a polymorphic hierarchy,  
it would be strange having to convert back and forth to variants in  
the grammar actions. Therefore I am for a more general support.

> By the way, I've not used the "%union" construct for the definition of
> the different types as I saw no way to get rid of the braces in the
> generated muscle.

There is no way to get rid of those braces, but to rewrite the code...

> Personally I think that the "%define variant"
> approach is a fairly clean solution.

...which Akim recently has done for %define.

> In any case, thank you for the quick reply to my submission. I
> sincerely hope that this or another solution will make it to the next
> release of Bison (so we finally get rid of manual object destruction).
> Further comments/test results are very welcome!

It has been in the wait for years, so do not hold your breath.

  Hans Aberg