Jump to content
  • Advertisement
Sign in to follow this  
clearly

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

This topic is 4342 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 )

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. :-)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
the compile wont rewrite your functions to avoid the temporary in this case...

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!