Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > When to use overloaded operators

Reply
Thread Tools

When to use overloaded operators

 
 
Jim Langston
Guest
Posts: n/a
 
      08-05-2007
"Daniel Kraft" <(E-Mail Removed)> wrote in message
news:f945na$iv6$(E-Mail Removed)...
> Hi all,
>
> I'd like to know your opinion on when you think overloaded operators
> should/could be used instead of "ordinary methods". Of course, they are
> essential for generic programming and there are some nice "hacks" for
> expression templates, like Boost's Spirit library.
>
> But personally, I tend to use them also for "methods" of objects, which to
> something "conceptually similar" to what the overloaded operator does
> usually.
>
> For instance, in a current project of mine, I have a class whose instances
> define behaviour for "merging" with other objects of that class and for
> "finding the differences"--this made me think to have operator| instead of
> merge and operator& instead of comparation.
>
> Would you recommend such practice or should I stick to "merge" and
> "compare" as simple method names?


Operator overloading only makes sense when the functionality you are
creating is related somewhat to the operator. operator| for a merge and
operator& for a comparison don't make much sense to me. It would take a
stretch of the imagination for a programmer to figure out that operator| is
merging as a bitwise or "merges". It's not intuitive. Personally, I would
go with merge() and compare().


 
Reply With Quote
 
 
 
 
=?ISO-8859-1?Q?Erik_Wikstr=F6m?=
Guest
Posts: n/a
 
      08-05-2007
On 2007-08-05 13:36, Daniel Kraft wrote:
> Hi all,
>
> I'd like to know your opinion on when you think overloaded operators
> should/could be used instead of "ordinary methods". Of course, they are
> essential for generic programming and there are some nice "hacks" for
> expression templates, like Boost's Spirit library.
>
> But personally, I tend to use them also for "methods" of objects, which
> to something "conceptually similar" to what the overloaded operator does
> usually.


Use operators where it would make sense to a person familiar with the
concepts modelled by the classes. Since most operators are mathematical
this rule kind of limits the applicability to mathematical concepts or
places where an specific meaning has been assigned to an operator
convention (i.e. using + to concatenate strings).

> For instance, in a current project of mine, I have a class whose
> instances define behaviour for "merging" with other objects of that
> class and for "finding the differences"--this made me think to have
> operator| instead of merge and operator& instead of comparation.
>
> Would you recommend such practice or should I stick to "merge" and
> "compare" as simple method names?


What is it you merge and compare? If they can be considered to be sets
then + would probably be better for union (merge) and - can be used for
set difference (probably not for intersection though).

--
Erik Wikström
 
Reply With Quote
 
 
 
 
Daniel Kraft
Guest
Posts: n/a
 
      08-05-2007
Hi all,

I'd like to know your opinion on when you think overloaded operators
should/could be used instead of "ordinary methods". Of course, they are
essential for generic programming and there are some nice "hacks" for
expression templates, like Boost's Spirit library.

But personally, I tend to use them also for "methods" of objects, which
to something "conceptually similar" to what the overloaded operator does
usually.

For instance, in a current project of mine, I have a class whose
instances define behaviour for "merging" with other objects of that
class and for "finding the differences"--this made me think to have
operator| instead of merge and operator& instead of comparation.

Would you recommend such practice or should I stick to "merge" and
"compare" as simple method names?

Yours,
Daniel

--
Got two Dear-Daniel-Instant Messages
by MSN, associate ICQ with stress --
so please use good, old E-MAIL!
 
Reply With Quote
 
Michal Nazarewicz
Guest
Posts: n/a
 
      08-05-2007
> On 2007-08-05 13:36, Daniel Kraft wrote:
>> For instance, in a current project of mine, I have a class whose
>> instances define behaviour for "merging" with other objects of that
>> class and for "finding the differences"--this made me think to have
>> operator| instead of merge and operator& instead of comparation.
>>
>> Would you recommend such practice or should I stick to "merge" and
>> "compare" as simple method names?


Erik Wikström <(E-Mail Removed)> writes:
> What is it you merge and compare? If they can be considered to be sets
> then + would probably be better for union (merge) and - can be used
> for set difference (probably not for intersection though).


I guess * may be used for intersection and ^ for symmetric difference
(ie. ((a\b) + (b\a))).

However, | and & may make some sens as well - ie. a | b -- elements in
set a OR set b, a & b -- elements in set a AND set b -- even though I'd
prefer +, -, *, ^.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
 
Reply With Quote
 
tony_in_da_uk@yahoo.co.uk
Guest
Posts: n/a
 
      08-06-2007
On Aug 5, 8:36 pm, Daniel Kraft <(E-Mail Removed)> wrote:
> For instance, in a current project of mine, I have a class whose
> instances define behaviour for "merging" with other objects of that
> class and for "finding the differences"--this made me think to have
> operator| instead of merge and operator& instead of comparation.


I think you've answered your own question here: for int, the compiler-
generated operator| might reasonable be though of as merging the
values, but operator& does nothing like "finding the differences". It
actually finds the non-different bits, i.e. the common bits. So, if
you yourself picked a broken analogy, what chance have other people
got to use your class properly? Other people who've replied have
already suggested other operators.

So, in general it's best to stay away from the whole issue unless the
choice of operator is very clear-cut, and you find people's
expectation of the operators' affects are largely consistent (i.e.
everything intuitive). But, if the class will be deployed in a very
specific yet large area of code, then it may be worth using operators
that are initially confusing if they - once learned - provide
substantial benefits in concisions and clarity. Contrast this with
code to be spread thinly as occasional support code in other generally
unrelated code, where strange conventions won't be appreciated....

Cheers,

Tony

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
accessing/overloading parent overloaded operators NKOBAYE027 C++ 2 05-08-2004 03:24 PM
c++ newb asks about overloaded operators Pete Wilson C++ 1 04-03-2004 03:28 PM
Inheriting overloaded operators Andy Jarrell C++ 5 11-13-2003 11:32 PM
Strange Results with Overloaded Operators John Harrison C++ 5 07-29-2003 12:42 AM
Overloaded Operators Problems -Steve- C++ 2 07-28-2003 03:25 AM



Advertisments