bug-bison
[Top][All Lists]
Advanced

[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






reply via email to

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