function representation in ginac

[Richard B. Kreckel]

On Wed, 31 Jan 2001, Alexander Frink wrote:
> IIRC one of the main reasons against the one-class-per-function
> scheme was that that the preprocessor is not very powerful.
> Since a function can have either default or user implemented
> diff, series, evalf etc. methods, one would need many macros
> implementing all possible combinations. The notation for the user
> to define his own functions would look horrible (at least we
> could not find a better one).
> 
> Further each GiNaC class unfortunately needs some supporting
> code (copy(), destroy(), duplicate() etc.) which would have to be
> generated for each class representing a function again and again
> blowing up code size.

I do not see why all this could not be done by virtual functions.
Am I to be missing some obvious point?

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


-
To UNSUBSCRIBE, email to ginac-list at ginac.de with a subject of "unsubscribe".