CCPoint overloaded operators (+, -, *, /)


Hi there,

is there any particular reason the CCPoint class , -, * & / operators are not overloaded?
The implementation is really easy, and it really cleans up the code a lot while makes the code less error prone. It’s also consistent with box2d, that has the operators overloaded for b2Vec2.
Doesn’t everybody prefer this:
point 4 = * 2
(point2 + point3) * 2;

instead of this?

point 4 = ccpAdd(ccpMult(ccpAdd(point1 + point2), 2), ccpMult(ccpAdd(point2 + point3), 2));

If you are not against it I could do a pull request :slight_smile:


I agree, we would avoid some unnecessary complexity, the code would be much more readable (and writable :-))


Xavier Arias wrote:

If you are not against it I could do a pull request :slight_smile:

I think that is a good idea and I don’t see any reason why cocos2d-x team would not merge that to their repository.


Seemed to me like a too obvious thing to let out, so I figured that there would be a design decision there.


we did this in cocos2d-xna and it helped with the readability of the code.


I submitted the following pull request :


Yes! How do you feel about overloaded CCSize operators as well? Imo,

  CCSize size = CCSize(64, 64);
  CCSize otherSize;
  otherSize = size/2;

instead of

  CCSize size = CCSize(64, 64);
  CCSize otherSize;
  otherSize = CCSize(size.width/2, size.height/2);

Is much more readable. All the operators would make this more intuitive


Thanks Adrien Beraud!

Justin Godesky: I don’t find them as necessary as the CCPoint ones, but they would be welcome as well as beign able to crete points from sizes (and vice versa) easier through assignment.

For example:

CCSize winSize = CCDirector::sharedDirector()->getWinSize();
CCPoint screenCenter = winSize / 2;

This can be achieved overloading operator=(const CCSize&) in CCPoint.


Dustin Yoste wrote:

I assumed this was a performance decision.
Using the standard operators would create more instances than needed.
During run time if these are used frequently, it would affect frame rate more than the operator equals operators since they’re not allocating anything themselves (for the most part).

CCPoint does not allocate anything, it is a plain, easy to optimize class, statically allocated on the stack in most cases.

Overloading would not lead to more instructions than calls to ccpAdd since ccpAdd (and such) actually calls the CCP constructor itself.
Actually overloading may make the task easier for the compiler to vectorize the computation on supported architectures.


Dustin Yoste wrote:

Using a + operator rather than ccpAdd would create a temporary instance. That’s what I meant by allocate.
The ccpAdd function acts as a = operator right?
I did edit my post, prior to deleting it, to note the fact that because of this, we end up creating the temporary instances ourselves, as the OP showed in his example.
I agree it would be better to have normal operators. I was just stating what I thought the design decision behind not doing so was.
Not having the normal operators forces us to only create the temporary instances when needed.
ccpAdd is the same as the proposed operator
but less readable ( as you can see in CCPointExtension.h it does call the constructor through ccp() which is a shortcut for CCPointMake which is a “shortcut” (sic) for CCPoint(x,y) ).

In practice the class is so simple that the compiler would optimize-out inline or method-local temporary instances no matter how the code is written (expect for ugly cases with pointers to CCpoints and such).

But to be sure that RVO is applied, the lastest PR simplifies the constructor and the overloaded operators (see ).

edit: why do you delete your posts ?


The pull request have been merged.

It includes operator overload for CCPoint + CCSize, implicit conversion between both ( e.g. mySpr.setPosition(winSize/2); ), and it moves most cppXX functions to CCPoint such as length() etc.