is there any better way of writing operators in c++?

Started by
31 comments, last by Deyja 17 years, 9 months ago
http://rafb.net/paste/results/gWylDH99.html some one told me that it is wrong to write it like that and that there is a better way..?
Advertisement
You might take a look at this; it addresses operator scope (which I'm guessing is what the person was referring to), along with some other operator-related topics.
1) Assignment style operators typically return a reference.
2) Having operator+ use operator+= can often save on logic duplication for anything nontrivial - e.g.:

friend MyInt operator+( const MyInt & lhs , const MyInt & rhs ) {  MyInt temp( lhs );  temp += rhs;  return temp; }


3) One typically wants to use the above instead of the operator+ with the implicit this, since this will allow: 5 + MyInt( 42 )
Quote:Original post by MaulingMonkey
2) Having operator+ use operator+= can often save on logic duplication for anything nontrivial - e.g.:


I like doing it the other way around: having operator+= use operator+. It just makes more sense because operator+ is more general and operator+= is more specific.
deathkrushPS3/Xbox360 Graphics Programmer, Mass Media.Completed Projects: Stuntman Ignition (PS3), Saints Row 2 (PS3), Darksiders(PS3, 360)
Doing it that way removes the cheif advantage of using operator += in the first place. operator+ requires the creation of a temporary; operator += does not.
Quote:Original post by Deyja
Doing it that way removes the cheif advantage of using operator += in the first place. operator+ requires the creation of a temporary; operator += does not.


I never thought about it that way. I kind of trust the compiler to optimize the obvious. :-)
deathkrushPS3/Xbox360 Graphics Programmer, Mass Media.Completed Projects: Stuntman Ignition (PS3), Saints Row 2 (PS3), Darksiders(PS3, 360)
the compile wont rewrite your functions to avoid the temporary in this case...
Quote:Original post by deathkrush
Quote:Original post by Deyja
Doing it that way removes the cheif advantage of using operator += in the first place. operator+ requires the creation of a temporary; operator += does not.


I never thought about it that way. I kind of trust the compiler to optimize the obvious. :-)


Which is fine when it's obvious, but in more complex scenarios (especially if the code depends on other APIs) it becomes far less so. Given that it's mainly a cosmetic difference in terms of programming, it's a good habit to use the one that will "allways" work best - just like it ++i instead of i++ used to be recommended (and still probably will be).
Quote:Original post by clearly
http://rafb.net/paste/results/gWylDH99.html
some one told me that it is wrong to write it like that
and that there is a better way..?
If your are referring to the ++ operators from that link, the post increment is incorrectly imlemented. It should return copy of the old object, not a reference to the incremented object.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms
I would suggest making MyInt( int ); different. Right now it can be implicitly casted from any int to MyInt, which can lead to confusion and troubles. Instead write it:
explicit MyInt( int );

Also I agree that += should be implemented in terms of +. You lose the benefit of no temporary, that is true. But you gain exception safety.
Case 1: If += begins modifying itself and an exception occurs half way through, the object is no longer correct and you are not exception safe.
Case 2: If += calls + and the exception occurs in +, the object's state hasn't been altered and you can propogate the exception.

This topic is closed to new replies.

Advertisement