[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Hans Aberg
Subject: Re: A polymorphic YYSTYPE for C++ (instead of the %union)
Date: Sat, 16 Jun 2007 14:32:36 +0200

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]