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.

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

Quote:

---

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.

Quote:

---

Originally Posted by CornedBee

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.

---

There's really no reason for a "complex" class to have anything other than the real and imaginary parts in it. I'd just make them both public, then write the operators as standalone functions, no need for friend.

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?

Quote:

---

Originally Posted by TriKri

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

---

C has structures which are always completely public. That hardly makes them useless. Data aggregation and encapsulation are two different concepts.

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