cok@islsun.Kodak.COM (David Cok) (02/13/91)
I and others recently completed a package of C++ classes in which we tried to
provide both strong typing and inheritance and we ran into the following
situation, in which the two requirements conflicted.
We had a base class Image from which some derived classes DoubleImage,
FloatImage, IntImage etc. were derived. We defined lots of relevant
functions including (for example) operator- .
Now intuitively operator- applied to a DoubleImage produces a new
DoubleImage value and similarly for the other derived classes. With this and
strong typing in mind, we defined member functions of the form
const DoubleImage& DoubleImage::operator-() const;
const FloatImage& FloatImage::operator-() const;
But we also want some "virtualness" here. If we apply operator- to an Image
we should get a new Image, having applied the correct - operator depending on
the runtime derived type. That is we want:
const Image& Image::operator-() const;
The resulting partial program is
Example A:
class Image {
public:
virtual const Image& operator-() const = 0;
};
class DoubleImage: public Image {
public:
const DoubleImage& operator-() const;
};
BUT THIS IS ILLEGAL because the two operator- declarations do not return the
same type.
The best way we could find to give our desired interface was a kludge like this:
Example B:
class Image {
public:
virtual const Image& operator_minus() const = 0;
inline const Image& operator-() const
{ return this->operator_minus(); }
};
class DoubleImage {
public:
const Image& operator_minus() const; // the real work is here
inline const DoubleImage& operator-() const
{ return (DoubleImage&)(((Image*)this)->operator_minus());}
};
which has type-unsafe casts and twice the number of functions.
Question 1: Does anyone have a better suggestion?
Question 2: What is the rationale for requiring that the implementations of
virtual functions in derived classes return exactly the same type as is
declared in the base class? It would seem sufficient to require
that the declaration in a derived class return a type which can be
converted (using at least some set of implicit conversions) to that
used in the base class. For example,
if the base class returns Image& the derived class may return
DoubleImage& ; if the base class returns Image*, the derived class
may return DoubleImage* .
This simple relaxation of the rule would not break any existing C++
code. The compiler can type-check everything just as well, and it would
help avoid the problem of needing casts ("casts considered harmful...")
to avoid types drifting to the top of the inheritance tree.
It would have simplified our code above greatly -- almost
every function needed a virtual internal function so that we could
get the correct interface and virtual behavior as well.
It does require the compiler to do a little work. Consider the rule relaxed to
allow at least the pointer and reference conversions indicated above, and add to
example A above the corresponding declaration of FloatImage::operator-().
Applying operator- to a FloatImage& would simply return a FloatImage&. Applying
operator- to an Image& needs to return an Image&. The compiler needs to create
a version of FloatImage::operator- which converts its FloatImage& result to an
Image& and a version of DoubleImage::operator- which converts its DoubleImage&
result to an Image& (change all references to pointers if you like). For these
conversions that is trivial; more complicated conversions (which may not be
allowed) or the presence of MI would mean some real work had to be done. In
effect, the compiler converts example A into example B, but does so in a
type-safe manner. When the programmer does it with casts, type-checking is
lost.
David R. Cok
Eastman Kodak Company
cok@Kodak.COM
716-477-7086schweitz@lexvmc.iinus1.ibm.com ("Eric Schweitz") (02/19/91)
| David R. Cok | Eastman Kodak Company | cok@Kodak.COM | 716-477-7086 writes: | We had a base class Image from which some derived classes DoubleImage, | FloatImage, IntImage etc. were derived. We defined lots of relevant | functions including (for example) operator- . | | ... we defined member functions of the form | | const DoubleImage& DoubleImage::operator-() const; | const FloatImage& FloatImage::operator-() const; | | But we also want some "virtualness" here. Perhaps you could tell us why you `needed' these member functions to be virtual. | Example A: | | class Image { | public: | virtual const Image& operator-() const = 0; | }; | | class DoubleImage: public Image { | public: | const DoubleImage& operator-() const; | }; | | BUT THIS IS ILLEGAL because the two operator- declarations do not return the | same type. You're right here. However, if ``operator-'' had been declared as a non-`pure virtual' member function, you would have simple overloading of the unary ``-'' operator. | Question 1: Does anyone have a better suggestion? Yeah, don't make the operator- a pure virtual function if you don't have to. | Question 2: What is the rationale for requiring that the implementations of | virtual functions in derived classes return exactly the same type as is | declared in the base class? The rationale behind this is that it would make the following possible : //.... Image i, *ip; DoubleImage *dp; ip = &i; dp = func ((DoubleImage*) ip); //.... where, func () is: //.... DoubleImage* func (DoubleImage* p) { return p->operator-(); } //.... hence, func() would return a Image* to dp which is expecting a DoubleImage*. Schweitz. schweitz@lexvmc.iinus1.ibm.com
cok@islsun.Kodak.COM (David Cok) (02/19/91)
In article <9102182022.AA05904@ucbvax.Berkeley.EDU> schweitz@lexvmc.iinus1.ibm.com ("Eric Schweitz") writes: >| David R. Cok >| Eastman Kodak Company >| cok@Kodak.COM >| 716-477-7086 > >writes: > >| We had a base class Image from which some derived classes DoubleImage, >| FloatImage, IntImage etc. were derived. We defined lots of relevant >| functions including (for example) operator- . >| >| ... we defined member functions of the form >| >| const DoubleImage& DoubleImage::operator-() const; >| const FloatImage& FloatImage::operator-() const; >| >| But we also want some "virtualness" here. > >Perhaps you could tell us why you `needed' these member functions to be >virtual. > > > > ... > Craig Hubley already responded to the theory here: compile-time overloading vs runtime virtual function resolution, so I'll just provide the pragmatic justification for wanting an unusual thing like virtual functions. We were putting together a package to support image processing and hence had classes DoubleImage, FloatImage, IntImage etc derived from Image. Some operations apply only to specific classes: bit twiddling on IntImages for example. Others apply to all the derived classes (+ - negation * / etc.). If one knows at compile time that an Image has a certain pixel data type, one wants the compiler to do type checking -- hence strong typing. However, often one does not know the pixel data type at compile time, such as if the image were read in from a disk file. Then it must be passed around as an Image* and virtual functions are needed to act upon it. Obviously, if one is going to do any type-specific operations (e.g. bit anding) one has to check the dynamic type somehow at run-time. But, one can write useful routines which use only virtual functions (e.g. convolution: pad around the edge of the image with 0's (or whatever); loop over the image taking sums and products of neighboring pixel elements). If one were restricted to compile-time overloading, this routine would have to be duplicated -- until templates come around -- for every derived type. Is that enough to `need' virtual member functions? David R. Cok Eastman Kodak Company cok@Kodak.COM
craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/20/91)
In article <1991Feb19.124328.23934@kodak.kodak.com> cok@islsun.Kodak.COM (David Cok) writes: >In article <9102182022.AA05904@ucbvax.Berkeley.EDU> schweitz@lexvmc.iinus1.ibm.com ("Eric Schweitz") writes: >>| We had a base class Image from which some derived classes DoubleImage, >>| FloatImage, IntImage etc. were derived. We defined lots of relevant >>| functions including (for example) operator- . >>| >>| ... we defined member functions of the form >>| >>| const DoubleImage& DoubleImage::operator-() const; >>| const FloatImage& FloatImage::operator-() const; >>| >>| But we also want some "virtualness" here. >> >>Perhaps you could tell us why you `needed' these member functions to be >>virtual. >> ... > >Craig Hubley already responded to the theory here: compile-time overloading >vs runtime virtual function resolution, so I'll just provide the pragmatic >justification for wanting an unusual thing like virtual functions. "unusual" ? >We were putting together a package to support image processing and hence had >classes DoubleImage, FloatImage, IntImage etc derived from Image. Some >operations apply only to specific classes: bit twiddling on IntImages for >example. Others apply to all the derived classes (+ - negation * / etc.). >If one knows at compile time that an Image has a certain pixel data type, one >wants the compiler to do type checking -- hence strong typing. However, >often one does not know the pixel data type at compile time, such as if the >image were read in from a disk file. Then it must be passed around as an >Image* and virtual functions are needed to act upon it. Obviously, if one is >going to do any type-specific operations (e.g. bit anding) one has to check >the dynamic type somehow at run-time. But, one can write useful routines >which use only virtual functions (e.g. convolution: pad around the edge of >the image with 0's (or whatever); loop over the image taking sums and products >of neighboring pixel elements). If one were restricted to compile-time >overloading, this routine would have to be duplicated -- until templates come >around -- for every derived type. You provide a good example of a capability that can be provided by templates (parametrized polymorphism) or inheritance (hierarchical polymorphism). It seems to me that in the case that you describe, either could solve it. But which method leaves you more flexibility for extension ? If the functions you write would apply to any type, without needing to be adjusted for different class hierarchies, then it is a good candidate for a template. However, if you are writing functions specific to a given class hierarchy, as you seem to be here, you would like to take advantage of the relationship that these types already have. In other words, you would rather these functions be members than be free, because they are really part of the type specification rather than part of the application specification. If you do this with templates you will be hauling them around with the Image class hierarchy and so they are effectively part of it. I often find it necessary to use *all* the polymorphism power of C++ (overloading, conversion, public derivation) to provide a uniform and consistent set of behaviors to the user. Templates add some power to that, but they are not a substitute for a unified resolution or assertion mechanism. >Is that enough to `need' virtual member functions? In theory, sure. In C++, apparently not. :) At least once templates are widespread you will have a way to do this, even if (to my mind) it's not the best way. >David R. Cok >Eastman Kodak Company cok@Kodak.COM -- Craig Hubley "...get rid of a man as soon as he thinks himself an expert." Craig Hubley & Associates------------------------------------Henry Ford Sr. craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig