Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.object
Subject: Re: inheritance and `type loss'
Message-ID: <56119@microsoft.UUCP>
Date: 27 Jul 90 18:08:15 GMT
References: <SRA.90Jul10155606@alonzo.ecs.soton.ac.uk> <1990Jul26.120125.7955@tukki.jyu.fi>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: comp
Organization: Microsoft Corp., Redmond WA
Lines: 52

In article <1990Jul26.120125.7955@tukki.jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) writes:
>In article <SRA.90Jul10155606@alonzo.ecs.soton.ac.uk> sra@ecs.soton.ac.uk (Stephen Adams) writes:
>1. Simula and many others (including C++ and Eiffel) don't even pretend
>   that 'integer' is a class; thus you cannot create any subclasses
>   from it.

Yes, except with about a page of code C++ allows you to turn the 
built-in primitive 'int' [or other primitive] into a a true class 'Int'
than acts 'identical' to an int, but now is a full-class class, and can
be subclassed.  See Hanson "The C++ Answer Book" for the 'right' way to
do this.

>In C++ you can actually define distinct methods for each of the three
>above operand type pairs and give each of them exactly the result type
>that you like, independently. The appropriate method will then be selected
>at compile time; so if you use pointers to objects, the actual run-time
>class of the objects pointed to has no effect. 

Yes and no -- it depends on how you program it.  Using the matrix/vector
example, one might want to define something like:

matrix& operator*(matrix& m, vector& v);
matrix& operator*(matrix& m, matrix& v);
....

where matrix and vector are really appropriate protocols.  Then one could
define various concrete classes answering these protocols:  packed_matrix,
sparse_matrix, packed_vector, packed_matrix.... and the overloaded operators
make sure that the right protocols get selected when something like:

	a_sparse_matrix_ref * a_packed_vector_ref;

is written.  In general, then one has to explicitly program to get a virtual
virtual function dispatch off both the left hand side and the right hand side
in order to get to the actual do-the-work function, say:

matrix& MpySparseMatByPackedVector(sparse_matrix& m, packed_vector& v).

But, the nice thing is that the protocols are type-checked at compile time
so that things like:

	a_sparse_matrix_ref * a_banana_ref;

are caught at compile time [ assuming bananas aren't part of the math
system you want to define :-]

The real problem is that unless one is clever, one ends up implementing
O(n^2) actual add or multiply routines that do the hard work.  "Clever" in
this particular example *might* mean making operator[] virtual, so that
multiply and add routines can be written that don't care about the sparse-ness
or packed-ness of a matrix or vector.  This might reduce the problem such
that there are only four flavors of each of add, sub, mpy, ....