Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!uunet!ogicse!orstcs!fog.CS.ORST.EDU!budd
From: budd@fog.CS.ORST.EDU (Tim Budd)
Newsgroups: comp.lang.c++
Subject: Re: To template or not
Message-ID: <1991Jun13.163831.20232@lynx.CS.ORST.EDU>
Date: 13 Jun 91 16:38:31 GMT
References: <1991Jun12.193426.8289@lynx.CS.ORST.EDU> <1991Jun13.143127.19044@kodak.kodak.com>
Sender: @lynx.CS.ORST.EDU
Organization: Computer Science Department, Oregon State Univ.
Lines: 25
Nntp-Posting-Host: fog.cs.orst.edu

In article <1991Jun13.143127.19044@kodak.kodak.com> cok@islsun.Kodak.COM (David Cok) writes:
>
>Not necessarily, the property of two things matching is part of the definition
>of the things, not of the list of things.  To be specific -- and use the
>example below -- the property of equality of Cards should be a method of
>Cards, not on CardLists.  Thus there would be a method
>
>	int Card::operator==(Card* b) { return (suit()==b->suit() && rank() == b->rank());} 
>

This misses the point of point (c).  The container classes must be able to
hold ARBITRARY objects.  In particular, you can't be assured that the 
things being held will respond to ==.  This is because the containers
must be able to hold objects that have been developed elsewhere, are
perhaps available only in binary, but in any case can't be touched (and you
thought dusty decks happened only in FORTRAN!).

I agree with David in as much as *IF* you are designing the containers AND
he objects they will hold, then overriding == is the correct solution.
But it's not the general solution.  (I thought about making it the default
in a virtual method in the template class, but even that won't work.
If the objects being held don't recognize ==, then even if the method is
overridden the compiler will still try to compile the original method, and
will complain).
--tim budd