Question

The exact situation is next:
I have defined in system API structs CGPoint and CGSize, and I want to be able to write my_point = my_size.
I can’t modify CGPoint struct, only can write external operator. I can write binary operators (+, -, …) but operator= must by declared inside struct. So is there any other solution?

Answer 1

To make the expression a = b; compile you need to either have an operator= in the type of a that takes an element of the type of b, or a type implicitly convertible from b.

The first case is ruled out, since operator= must be a member of the class, and since you cannot modify GLPoint then you cannot add GLPoint& GLPoint::operator=( GLSize ).

The second case suffers the same type of problems. An implicit conversion from GLSize to GLPoint can be implemented as an implicit constructor in GLPoint (ruled out), or as a member operator GLPoint() in GLSize, which requires modification of GLSize. Conversions cannot be added as free functions either.

The alternatives are using non-operator syntax, as adding a free function assign (or copy): GLPoint& assign( GLPoint&, GLSize const & ).

The next question is why would you want to do so. If the designers of GLPoint and GLSize did not consider that a size should be assignable to a point, then why do you feel that they should be assignable? In general it is a good idea to keep types separate, as that will enable the compiler to detect mistakes you might make in your code.

If you allow implicit conversions from GLSize to GLPoint, you might by mistake type something like: distance( point1, size2 ) where you meant distance( point1, point2 ), and because there is a conversion, the compiler will gladly convert and apply. Then you will see strange results, and you will spend quite a few nice debugging hours trying to determine where the logic is wrong.

Unless the domain has a very clear definition of what each operator means in that context, I would avoid operator overloading at all costs. Will everyone reading your code immediately understand what GLPoint(1,2) + GLSize(5) represents without any doubt or ambiguity? If that is not the case, if people will be surprised or even doubt, then avoid operator overloading and use named functions: move_up( GLPoint&, GLSize ) (or whatever point+size means to you)