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