GiNaC/ginac basic.cpp numeric.cpp operators.cpp power.cpp pseries.cpp symbol.cpp wildcard.cpp

Richard B. Kreckel kreckel at thep.physik.uni-mainz.de
Mon Aug 20 14:42:39 CEST 2001


On Sat, 18 Aug 2001, Pearu Peterson wrote:
> > - carried on with felonious plot about making ex::bp private.
> 
> Sorry that I haven't checked out the details of this evil plot as I am
> a bit afraid it will broke something in my project (pyginac - Python
> interface to GiNaC). But here follow my concerns. 
> For this interface I use the following expressions:
>   e.bp->precedence();
>   e.bp->class_name();  
>   (GiNaC::lst &)(*(e.bp));
>   (GiNaC::numeric &)(*(e.bp));
>   (GiNaC::symbol &)(*(e.bp));
>   etc.
> where e is an ex instance.
> 
> Will there be ways to write these expressions after your plot is complete?

Short answer:  don't panic.  :-) 

Long answer:

After the evil plot is completed the above won't compile, of course.  

Then you would have to write `ex_to<basic>(e).precedence()' or
`ex_to<expairseq>(e).precedence()' or whatever (it doesn't really matter)
for the first example.  Please note that by virtue of ex_to's return value
being a reference, it is still susceptible to dynamic type-dispatch, which
is what your concern boils down to.  You can (and should) already write it
this way.  Have a look at the last batch of changes to see how these things
translate.  In particular, the usage of `foo::is_equal(const basic &)' 
inside `foo::degree(const ex &)' is somewhat touchy, but the last changes
compile to exactly the same:

<http://down.physik.uni-mainz.de/cgi-bin/viewcvs2.cgi/GiNaC/ginac/symbol.cpp.diff?r1=1.37&r2=1.38>

Regards
    -richy.
-- 
Richard Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>





More information about the GiNaC-devel mailing list