[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: too many warnings from Bison CVS for Pike
From: |
Hans Aberg |
Subject: |
Re: too many warnings from Bison CVS for Pike |
Date: |
Sat, 25 Feb 2006 07:48:42 +0100 |
On 21 Feb 2006, at 19:34, Joel E. Denny wrote:
If this usage is fine, then I wonder how "lalr1.cc" supports non-
POD types
more than "yacc.c". A footnote in the same section says that
`pseudo-unions' may alleviate this need for pointers in the
future. So,
are you referring to future plans rather than current support?
Here is a crash course:
One way to achieve a very simplistic form of C/C++ (dynamic)
polymorphy, is by a union:
union data {
X1 x1;
...
Xk xk;
};
This is untyped polymorphy, as the active field is not kept track of.
Bison's static type system helps the programmer doing this tracking.
This simplistic model does not work if the types, be it in C (via
hands on OOP) or C++ (via built-in OOP), have non-trivial assignment
operators and destructors (as in C++ non-POD types), as one does not
know which operator to apply. The traditional way to program around
this in C, is to add the type:
struct data_type {
enum type { ... };
type type_;
union data {
X1 x1;
...
Xk xk;
};
};
(external or internal to the class).
A problem with this model is that the base class must be altered
whenever a new type is added. Therefore the C++ "virtual" derived
class hierarchy model was developed, with RTTI (run-time type
identification) added. This is thought of as the C++ replacement of
the model above, though one can of course use other models.
Now, in the Bison type system, the problem seems to merely be that
that the active field is tied to the union syntax "x.xk" syntax. In a
more general setting, one needs a macro "select(x, xk)", which will
depend on the implementation model chosen for the polymorphy.
Since the idea of the Bison type system is to help the programmer to
keep track of the type in the untyped unions, it probably does not
matter from the point of view of Bison implementation which
programmer implementation model is used in a more general setting
when the extending this.
One should note that programs may use both the union and the pointer
polymorphy together, as a form of optimization. For example, in a
functional language interpreter, the union might be used for types
that fit into one word, and the pointer for those that do not. So it
is unwise for Bison to impose one or another implementation model here.
Hans Aberg
- Re: too many warnings from Bison CVS for Pike, (continued)
- Re: too many warnings from Bison CVS for Pike, Joel E. Denny, 2006/02/21
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/21
- Re: too many warnings from Bison CVS for Pike, Joel E. Denny, 2006/02/21
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/22
- Re: too many warnings from Bison CVS for Pike, Akim Demaille, 2006/02/22
- Re: too many warnings from Bison CVS for Pike, Akim Demaille, 2006/02/22
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/24
- Message not available
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/25
- Message not available
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/25
- Message not available
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/25
- Re: too many warnings from Bison CVS for Pike,
Hans Aberg <=