[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
Re: A polymorphic YYSTYPE for C++ (instead of the %union), Akim Demaille, 2007/06/25