Taking operator overloading too far?

[Andrue Cope [TeamB]]

I am currently designing an application that will process a source and
validate its contents by recalculating an MD5 for everything it
contains. The user can optionally provide a second source and have the
contents of that compared against the first.

In one configuration this equates to comparing two directory trees and
I had this idea of overloading the '==' operator for the class that we
already have that we use to iterate directory trees.

In pseudo code this might be:

TOVolIO_DirectoryTree src( "c:\\" ),
trg( "d:\\" );

if( src==trg )
ShowMessage( "The directory trees are identical" );

The main objection I have to this is that if you overload '=='
shouldn't you also overload '>' etc. (and what would '>' mean in this
context come to that)? I know that the language doesn't require it (in
the sense that as long as no one tries to use them there's no problem)
but I've always felt that if you overload one relational operator it is
best practice to overload them all.

The other objection I have is perhaps even more trivial. It somehow
feels 'wrong' to have calling an operator result in such a large amount
of activity. Then again the algorithm almost writes itself since of
course the file handling objects will also have an '==' overload.
--
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

[Chris Uzdavinis]

"Andrue Cope [TeamB]" <no....@not.a.valid.address> writes:

> The main objection I have to this is that if you overload '=='
> shouldn't you also overload '>' etc. (and what would '>' mean in this
> context come to that)?

I wouldn't worry about adding needless, hard-to-define operations.
Being able to tell if two things are equivalent is considerably
different than being able to put them into a meaningful "order".

Think of math equations. Either they are equivalent, even if they are
represented differently, or they're different, but it's hard to say
which math expression should come "first". Unless you define
specifically what it means for an ordering, creating one artificially
seems a waste of time, is confusing, and probably will lead to more
surprises than useful results.

> I know that the language doesn't require it (in the sense that as
> long as no one tries to use them there's no problem) but I've always
> felt that if you overload one relational operator it is best
> practice to overload them all.

That may be true for things that you want to sort, or put in certain
STL containers, etc., but I see no reason to invent operations that
have no meaning to appease a design heuristic that probably doesn't
fit in this case anyway.

> The other objection I have is perhaps even more trivial. It somehow
> feels 'wrong' to have calling an operator result in such a large amount
> of activity. Then again the algorithm almost writes itself since of
> course the file handling objects will also have an '==' overload.

I know what you mean, though it's hard to quantify. For some reason,
operators have the apperarance of doing little. Perhaps it's because
they're relatively detached from the objects on which they operate.
That is, syntactically, they're not connected to the object in a way
that calling a normal member function is. They're easy to overlook,
in that regard.

But if you're really testing for equality/equivalence (it's important
to be clear which you decide), then why not?

--
Chris (TeamB);

[Andrue Cope [TeamB]]

Chris Uzdavinis (TeamB) wrote:

> But if you're really testing for equality/equivalence (it's important
> to be clear which you decide), then why not?

You've convinced me :)

[Thomas Maeder [TeamB]]

"Andrue Cope [TeamB]" <no....@not.a.valid.address> writes:

> In one configuration this equates to comparing two directory trees and
> I had this idea of overloading the '==' operator for the class that we
> already have that we use to iterate directory trees.
>
> In pseudo code this might be:
>
> TOVolIO_DirectoryTree src( "c:\\" ),
> trg( "d:\\" );
>
> if( src==trg )
> ShowMessage( "The directory trees are identical" );

Not sure if I like it.

First (and not so important), == tests for equality, not identity. You
compare addresses or identifying attributes to test for identity.

Second, it's not clear to me what equality means. Do the files in the
tree have to have the same content, or also the same creation and
access times? What about permissions?

> The main objection I have to this is that if you overload '=='
> shouldn't you also overload '>' etc. (and what would '>' mean in this
> context come to that)?

Not necessarily. == applies to much more types than < and >.
E.g. std::find requires the value_type to be comparable using ==. <
and > are not required.

> The other objection I have is perhaps even more trivial. It somehow
> feels 'wrong' to have calling an operator result in such a large amount
> of activity. Then again the algorithm almost writes itself since of
> course the file handling objects will also have an '==' overload.

Using * for multiplying matrices feels very natural, doesn't it?

[Alisdair Meredith [TeamB]]

Andrue Cope [TeamB] wrote:

> The main objection I have to this is that if you overload '=='
> shouldn't you also overload '>' etc. (and what would '>' mean in this
> context come to that)?

By the same argument, would you say that complex number classes should
not implement operator== as you cannot (mathematically) order two such
numbers?

What about vector classes?

If operator== is clear in the context, then it is valuable. If it is
at all open to questions and vagueness, then I say use a named function
call instead. You might like to read Thomas reply to your question
before deciding how clear the equivalence is <g>

Always think about how someone else could mis-interpret your operator
overload before deciding to go with it. They are an incredibly
valuable shorthand for communicating ideas, cross language boundaries
well in international teams, beat easily lead to mis-understanding if
not 100% closed to mis-interpretation.

You also might like to search the web for comments by Dave Abrahams on
DSELs. Domain Specific Embedded Languages. This is something that C++
does very well, and I find it hard to think of operator overloading in
any other context now.

AlidairM

[Andrue Cope [TeamB]]

Thomas Maeder [TeamB] wrote:

> Second, it's not clear to me what equality means. Do the files in the
> tree have to have the same content, or also the same creation and
> access times? What about permissions?

Yes. Everything about them has to be the same aside from their physical
location. It's 'comp' on steroids :)

There will be an option to ignore some date/time stamps because not all
date/time stamps are transferred. Creation time is usually left alone.
In most cases though everything has to be identical and we will use it
to verify that our software is presenting a file system in the same way
that the host OS does.

> Using * for multiplying matrices feels very natural, doesn't it?

True.