On Mon, 29 Jan 2001, Richard B. Kreckel wrote:
We had the design you suggest before we switched to the current one. One drawback is that you cannot have classes share the name of global functions. Instead of writing sin(x) we had to write Sin(x). IIRC the code was much uglier with the old design and things got clearer when Alex came up with the cpp-register-functions-in-a-vector design. Alex, do you remember the precise circumstances?
Since this decision was made nearly two years ago, I don't remember the arguments exactly any more. It is possible to write sin(x)+y if sin is a class, since this is just a constructor call. However it would not be possible to pass a function pointer as a function argument (although we don't use such a construct). 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. OTOH I don't see any advantages using classes for functions. Mathematical functions rarely inherit something from other functions, so a flat hierarchy as implemented with the register function seems to be more natural to me. Best regards, Alex -- Alexander Frink E-Mail: Alexander.Frink@Uni-Mainz.DE Institut fuer Physik Phone: +49-6131-3923391 Johannes-Gutenberg-Universitaet D-55099 Mainz, Germany - To UNSUBSCRIBE, email to ginac-list@ginac.de with a subject of "unsubscribe".