Newsgroups: comp.lang.c++
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Subject: Re: C++ typing not so strong
Message-ID: <1991Feb19.205727.11676@gpu.utcs.utoronto.ca>
Organization: Craig Hubley & Associates
References: <9102182022.AA05904@ucbvax.Berkeley.EDU> <1991Feb19.124328.23934@kodak.kodak.com>
Date: Tue, 19 Feb 1991 20:57:27 GMT

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
