🚀 go-pugleaf

"Andrue Cope [TeamB]" <no.spam@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);

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 :)

-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

"Andrue Cope [TeamB]" <no.spam@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?