[Top][All Lists]
[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
- Union Type Object problem, Enrico Oliosi, 2004/08/05
- AW: Union Type Object problem, Olav Groehn, 2004/08/05
- Re: Union Type Object problem, Hans Aberg, 2004/08/05
- Re: Union Type Object problem, Laurence Finston, 2004/08/05
- Re: Union Type Object problem, Laurence Finston, 2004/08/05
- Re: Union Type Object problem, Hans Aberg, 2004/08/06
- Re: Union Type Object problem, Laurence Finston, 2004/08/07
- Message not available
- Re: Union Type Object problem, Hans Aberg, 2004/08/09
- Re: Union Type Object problem, Laurence Finston, 2004/08/08
- Re: Union Type Object problem, Hans Aberg, 2004/08/09
- Re: Union Type Object problem,
Laurence Finston <=
- Message not available
- Re: Union Type Object problem, Hans Aberg, 2004/08/10
- Re: Union Type Object problem, Laurence Finston, 2004/08/10
- Message not available
- Re: Union Type Object problem, Hans Aberg, 2004/08/11
- Re: Union Type Object problem, Laurence Finston, 2004/08/12
- Re: Union Type Object problem, Hans Aberg, 2004/08/12
- Re: Union Type Object problem, Laurence Finston, 2004/08/12
- Re: Union Type Object problem, Frank Heckenbach, 2004/08/13
- Re: Union Type Object problem, Laurence Finston, 2004/08/13
- Message not available
- Re: Union Type Object problem, Hans Aberg, 2004/08/12
- Re: Union Type Object problem, Laurence Finston, 2004/08/12