Thread: user defined operator returns another type?

How can I define an operator for a class, which has a return value of another class? For example:

class 1: real
class 2: imag
addition between the two results in a third class: complex

or maybe:
class: integer
division between two integers results in another class: fraction

Or even better, if it could return a variable of type variant<integer, fraction>, if the division gets evenly out it should return an integer.

Note: all classes in these examples are user defined.

Originally Posted by prog-bman

The same way you would overload it for a built in type or the class itself.

so

Code:

class real {
    double val;
public:
    complex operator+(imag);
};

class imag {
    double val;
};

complex real::operator+(imag a) {
    return complex(val, a.val);
}

But this code wont work, I'll have to make val a public member of imag, right? But that feels a litte bit strange, it can be private in real, but it has to be public in imag... :-/

You could make it a friend, but the better method is to provide a proper accessor. The imag class isn't very useful if there's no way to read or write the value, after all.

Yes, it's not like there are any restrictions on the values, or any special storage methods.

But what's the difference betweeen a class and a type if I make everyting public anway?

The choice of making the elements public or not in a class is something you have to seriously consider - the key question being:
- Will the way that we store the internal representation of the data change.

In the case of a complex class, the likelyhood is that you always will use double (or float) for the entire lifecycle of the application, because there really isn't any other good way to do that.

The same applies if you are developing a game that uses a "Vector3" which has "float x, y, z" to describe the vector - you don't really need accessor functions for that.

On the other hand, if you are to produce a string class, you wouldn't want to show the user how the string is stored internally - it is probably less useful in the first place, and you may want to store it differently in the future (e.g. if the string is often appended, you may have a linked list of string-segments, instead of re-allocating the string every time).

--
Mats