Re: Union Type Object problem

[Hans Aberg]

At 23:48 +0200 2004/08/09, Laurence Finston wrote:
>> The point is that dynamic_cast can in general only be resolved at compile
>> time. If you use void* in connection with polymorphy, then I think you may
>> decide on a fixed, static root class R, and then convert all polymorphy
>> types D to R first, and then converting R* to void*. When you convert back,
>> you must know from the static context which root class R it is. Once you
>> have gotten a R*, then you may apply a dynamic_cast<D*>(vp) if D is derived
>> from R. The result is a D* if vp is a pointer to a class derived from D,
>> otherwise 0 (modulo some protection stuff).
>
>I prefer `static_cast()' to `dynamic_cast()' because I believe it's a less
>expensive operation.   `dynamic_cast()' isn't needed because the information
>about the types of objects is available in the rules  --- usually the exact
>type, but sometimes a base class in a class hierarchy.

If your actions are such that each rule in effect is statically typed, then
you probably do not need dynamic_cast, and you can static_cast everything
back and forth to void*.

In a genuinely polymorphic approach, one does not need to write the rule
actions like that, but one can let the polymorphic system dynamically work
out what operations to apply. So essentially I work with a program creating
dynamic "closures", which generally depend on polymorphic operations not
directly related to the grammar. Then, sometimes, in the grammar rules, I
need to make a dynamic_cast, when I say need to apply the correct virtual
functions.

It does not make sense in this approach to try creating a statically typed
grammar handling, as the underlying program, parser taken away, is already
polymorphic. The grammar and parser are there simply to create a certain
class of legal input to the already polymorphic program. The program can in
reality cope with much more general types of polymorphy. (I am implementing
a theorem prover essentially based on first-order mathematical logic. But
the underlying modified Prolog system does not have any such first-order
restrictions, as I deliberately have removed them.)

But you are probably right, that any future C++ typed support in Bison
should perhaps be open for using static_cast's as well.

  Hans Aberg