From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: virtual operators
Keywords: Abstract Base Classes, general arithmetic
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 15 Oct 1992 14:24:03 GMT

In article <9210140947.aa26732@urmel.mathematik.uni-kl.de> Ralf Mueller <mueller@mathematik.uni-kl.de> writes:
>
>Hello all around there,
>we want to design and implement a class library for doing 
>mathematical (especially algebraic) computations.
>The class hierarchy we are thinking over looks as follows:
>
>   MathObject
>       |
>       +---------- Coefficient
>       |                |
>       |                +-------- Charp (Characteristic p numbers)
>       |                |
>       |                +-------- Rational
>       |                |
>       |                +-------- Integer (arbitrary long)
>       |                |
>       |                +-------- Polynomials over Coefficient
>       |                |
>       |                +-------- ...
>       |
>       +---------- Set of MathObject
>       |                |
>       |                +-------- ...
>       +---------- ...
>

	It isnt possible. Unless you remove the ... from the
diagram. Class oriented systems cannot do it.

	In any case, I'm not sure what it means. What are the
lines in the diagram? 

	If one uses inheritance and virtuals for subtyping,
then one must identify the subtypes.

>So we have virtual operators declared in class Coefficient, e.g.
>
>   class Coefficient : public MathObject {
>     public:
>       virtual Coefficient& operator += (Coefficient&) = 0;
>       virtual Coefficient& operator + (Coefficient&) = 0;
>       .

	no good is it. operator+ must return a value,
not a reference. 

>       .
>   }
>
>And 
> 
>   class Integer : public Coefficient {
>      private:
>        ... (the data members)
>      public:
>        ... (the virtual methods and some other Integer stuff)
>   }
>
>It is not possible to declare Coefficient::operator + (..) as
>
>   Coefficient operator + (...)

	On the contrary, it is essential to do this.
>
>because when downcasting Integer to Coefficient one loses the 
>data members of Integer.

	The diagram above specifies an ABSTRACT heirarchy
but one of the functions must return a CONCRETE object.
Hence it cannot be done.

	Btw, going from Integer to Coefficient is *upcasting*
not downcasting in my terminology.

>So the problem is when returning references from operator +,
>the created temporaries will never be destructed.

	Yes. The problem is that class based systems cannot
implement polymorphic functions of order greater than 1,
i.e. polymorphism only works for attributes.

>Another problem is that one can not work with Integer objects like
>
>   Integer a, b, c;
>   
>   a = b + c;

	Yes, you can. The way to do it is not to use polymorphism
to represent the subtyping between the abstractions. Instead,
just have a set of cooperating concrete classes.
>
>Solutions for our problems are as follows:
>(1) working with pointers, that means programs will lose their elegance,
>    because we must then write Integer *a, *b, *c; *a = *b + *c;

	This wont work. You have forgotten to destroy the object
that was pointed to by a.
>
>(2) implementing for every data type two classes, like:
>    
>    class Coefficient {
>      private:
>        InternalCoefficient *value;
>      public:
>        Coefficient& operator += (const Coefficient&);
>        friend Coefficient operator + (const Coefficient&, const Coefficient&);
>        ...
>    }
>    
>    class InternalCoefficient {
>      public:
>        virtual InternalCoefficient *add(InternalCoefficient*,....);
>        virtual InternalCoefficient *mul(.....);
>        ...
>    }
>
>    Then for class Rational we write:
>    class Rational : public InternalCoefficient {
>      private:
>        int numerator;
>        int denominator;
>      public:
>        .... (virtual functions from InternalCoefficient plus other methods)
>    }
>
>    But then one has to code every class twice, first an Internal
>    version working with pointers as described above and second a
>    friendly version in a mathematician's sight.
>

	I dont think this will work either.
>
>Are there any suggestions ???
>

	Make the classes concrete.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++