Re: Polymorphic abstract base class with operator=3D=3D or e= quivalen= t functionality; design considerations
On Sep 14, 7:49 pm, =?ISO-8859-1?Q?Daniel_Kr=FCgler?=
<daniel.kruegler@googlemail=.com> wrote:
{ Fixed Quoted Printable encoding, like "=" for "=". Perhaps it's our server
(back from the ashes) acting up, but, please check your settings. -mod/aps }
On 14 Sep., 00:55, BanMido <smartrefere...@gmail.com> wrote:
{ QP encoding detected and decoded. Check your settings. -mod }
Here is the scenario:
I am attempting to design a polymorphic abstract base class (i.e. an
interface), which will be extended, and its pure virtual functions
implemented, by a set of concrete classes.
I want all the concrete classes to support equality testing, so I
thought of adding a pure virtual 'operator==' method to the abs=
tract
base class which will be implemented by any concrete class
implementing the interface. But this approach poses some problems as
the signature of base class's 'operator==' method and derived c=
lass's
'operator==' method do not match.
E.g.
class IString
{
public:
virtual ~IString() {}
virtual unsigned int length() const = 0;
virtual bool operator==(const IString&) = 0;
virtual bool operator!=(const IString&) = 0;
To begin with, I consider it as a very *bad* idea,
to provide two virtual functions that are mutually
dependent: I have never seen a pair of
operator== and operator!= where the second
behaves different from the negation of the first.
If I would see something like this, this is probably
a design error. Allowing derived classes to
implement them differently is the best way
to allow for inconsistent classes.
I see my folly and I agree with you on that.
Second, I have only seen *rare* cases, where
a virtual operator==/!= makes sense and I
would always ensure that these are const
functions.
So, if your really want this, I suggest to
provide a single virtual function like this:
virtual bool is_equal_to(const IString&) const = 0;
and *possibly* (but not necessarily) the following
two non-member functions:
};
inline bool operator==(const IString& lhs, const IString& rhs) {
return lhs.is_equal_to(rhs);
}
inline bool operator!=(const IString& lhs, const IString& rhs) {
return !(lhs == rhs);
Yes, what I basically want is that the IString interface to guarantee
that all its implementers will provide a way to check for equality
among their objects.
The syntactic sugar provided by operator overloading is not really
necessary.
So, for that specific purpose, does my approach seem reasonable?
}
class CString : public IString
{
public:
CString :
strLen(0),
str(0)
{}
~CString() {}
virtual unsigned int length() const
{ return strLen; }
virtual bool operator==(const CString&)
{ return true; } // dummy implementation
virtual bool operator!=(const CString&)
{ return true; } // dummy implementation
Btw.: Even though this is just a "dummy"
implementation, you have already provided
an example where == and != are defined
inconsistently.
OK, I get your point. Thanks for pointing that out.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]