help-bison
[Top][All Lists]
Advanced

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

Re: Union Type Object problem


From: Laurence Finston
Subject: Re: Union Type Object problem
Date: Mon, 09 Aug 2004 23:48:24 +0200
User-agent: IMHO/0.98.3+G (Webmail for Roxen)

-------------------
> Hans Aberg 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.   In the latter case,
I cast to a base type and use virtual functions.  This information is
available at compile time so there's no need for me to use `dynamic_cast()'.  

For example, when the parser reduces a sequence of symbols to a `variable'
symbol, the code in the action examines the object associated with it, if
there is one.  There is only one type of object used for this purpose, called
`Id_Map_Entry_Type'.   It contains a data member `void* object' that points to
a `Pen', `Dash_Pattern', `Point', or whatever the variable is supposed to
represent (unless it's 0), and an `int' that represents the type of 
`Id_Map_Entry_Type::object'.  The action of the rule passes this `int' to
`yylex()'  which returns it to `yyparse()' immediately.   I call this 
"faking a token".  The parser resolves the sequence `variable <TYPE>' to a 
symbol `point_variable', `pen_variable', `dash_pattern_variable', or whatever.
  So for `variables', I pass the type information from the actions to the
rules.

`expressions' are another story, but there again, the types are known in the
rules. 

If anyone's interested in the details, my development sources are available
at:

http://savannah.gnu.org/cgi-bin/viewcvs/3dldf/3dldf/Group/CWEB/

Laurence



reply via email to

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