When to use overloaded operators

Discussion in 'C++' started by Jim Langston, Aug 5, 2007.

  1. Jim Langston

    Jim Langston Guest

    "Daniel Kraft" <> wrote in message
    news:f945na$iv6$...
    > 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().
     
    Jim Langston, Aug 5, 2007
    #1
    1. Advertising

  2. 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
     
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Aug 5, 2007
    #2
    1. Advertising

  3. Jim Langston

    Daniel Kraft Guest

    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!
     
    Daniel Kraft, Aug 5, 2007
    #3
  4. > 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 <> 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--
     
    Michal Nazarewicz, Aug 5, 2007
    #4
  5. Jim Langston

    Guest

    On Aug 5, 8:36 pm, 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.


    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
     
    , Aug 6, 2007
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. -Steve-
    Replies:
    2
    Views:
    372
    - Steve -
    Jul 28, 2003
  2. John Harrison
    Replies:
    5
    Views:
    329
    - Steve -
    Jul 29, 2003
  3. Andy Jarrell

    Inheriting overloaded operators

    Andy Jarrell, Nov 13, 2003, in forum: C++
    Replies:
    5
    Views:
    440
    Victor Bazarov
    Nov 13, 2003
  4. Pete Wilson
    Replies:
    1
    Views:
    320
    Mike Wahler
    Apr 3, 2004
  5. NKOBAYE027
    Replies:
    2
    Views:
    357
    NKOBAYE027
    May 8, 2004
Loading...

Share This Page