Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!mit-eddie!uw-beaver!cornell!rochester!kodak!islsun!cok
From: cok@islsun.Kodak.COM (David Cok)
Newsgroups: comp.lang.c++
Subject: Re: C++ typing not so strong
Message-ID: <1991Feb19.124328.23934@kodak.kodak.com>
Date: 19 Feb 91 12:43:28 GMT
References: <9102182022.AA05904@ucbvax.Berkeley.EDU>
Sender: cok@Kodak.COM
Organization: Eastman Kodak Co., Rochester, NY
Lines: 52

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