When to use overloaded operators

[Daniel Kraft]

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!

[Jim Langston]

"Daniel Kraft" <[e-mail] in message
news:f9**********@newsreader2.utanet.at...

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().

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

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

[Michal Nazarewicz]

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 <Er***********@telia.comwrites:

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

[tony_in_da_uk]

On Aug 5, 8:36 pm, Daniel Kraft <[e-mail]:

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