Thread: Operator Overloading

  1. #1
    Registered User
    Join Date
    Sep 2002
    Posts
    92

    Operator Overloading

    Hi all,
    I have a question about operator overloading. Suppose we have defined a overloaded operator as so...
    Code:
      // Implementing class TListIterator < T >
      template <typename T>
      int TListIterator<T>::operator == (const TListIterator<T>& I2) const
      {
        if (currLink == I2.currLink)
          return 1;
        return 0;
      }
    Can't we potentially define the != overloaded operator as:
    Code:
      template <typename T>
      int TListIterator<T>::operator != (const TListIterator<T>& I2) const
      {
        if(!operator==(I2))
          return 1;
        return 0;
      }
    ...since logically they both are direct opposites of each other? Thanks.

  2. #2
    carry on JaWiB's Avatar
    Join Date
    Feb 2003
    Location
    Seattle, WA
    Posts
    1,972
    Um...why would you want to do that? I don't believe it would work, and I can't see a good reason, but perhaps something like that would work...Off topic a bit, a better way to define == would be:

    Code:
     // Implementing class TListIterator < T >
      template <typename T>
      int TListIterator<T>::operator == (const TListIterator<T>& I2) const
      {
          return (currLink==I2.curLink);
       }
    
    //also != operator could be:
      int TListIterator<T>::operator != (const TListIterator<T>& I2) const
      {
          return (currLink!=I2.curLink);
       }
    basically, you can use the return statement to evalute the equality, instead of adding an if statement:

    currLink==I2.curLink logically returns 1 if they are equal and 0 if they are not equal, and currLink!=I2.curLink would return 1 if they are not equal and 0 if they are equal
    "Think not but that I know these things; or think
    I know them not: not therefore am I short
    Of knowing what I ought."
    -John Milton, Paradise Regained (1671)

    "Work hard and it might happen."
    -XSquared

  3. #3
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    Just to start off, JaWiB's suggestion of returning directly from the test makes sense. That operator already returns what you want (which, by the way, I believe would be a bool instead of an int since you are returning a logical value). Anyways, thats a rather trivial point, as what you have would work fine.

    Your method of defining one operator would work with a modification:
    Code:
    return !(*this == I2); // Use as an operator, not a function.
    It does have some drawbacks, however. One, it is significantly slower. The function has very few operations, and so the overhead of an extra function call would probably be significant (especially if you use the operator a lot). Also, with templates, generally the code for a function is not generated unless the function is actually called somewhere. By defining one templated function in terms of another, you are forcing == always to be generated if all you use elsewhere is !=.
    The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.

  4. #4
    Registered User
    Join Date
    May 2003
    Posts
    161
    Actually, the safest and most cohesive way to define operators is in terms of other operators. By doing this, if you change one operation (like equality) the other operators (like inequality) will automatically change to suit the new rules.

    Another common usage is something like this:

    Code:
    template <typename T>
      TListIterator<T>& 
      TListIterator<T>::operator+=(const TListIterator<T>& rhs)
      {
        currLink += rhs.curLink;
        return *this;
      }
    
    
    template <typename T>
      TListIterator<T> 
      TListIterator<T>::operator+(const TListIterator<T>& rhs)
      {
        TListIterator<T> ret = *this;
        ret.operator+=(rhs); // this syntax is legal
        return ret;
      }
    As for function call overhead, any decent compiler would inline these methods to effectively reduce the overhead to zero.

Popular pages Recent additions subscribe to a feed