Conversion constructor for template class

Hi everyone,

Real numbers become complex numbers when the second argument of an operator+, or the argument of an operator +=, is a complex number.

I have made a type 'Real' as a typedef of 'double', and a type 'Complex' as a class (with all necessary operators). 'Complex' has a one-argument constructor with 'Real', but now I would like to have an operator+, or operator+=, for my 'Real' which converts the real number in a complex number.

Should I make a separate class 'Real' ? I think that this will have a huge impact on performance, since now all my variables will no longer be written directly on the stack, as is the case (if I'm correct) with the primitive types in C++.

Thanks for any help!

There is no reason why user-defined types couldn't be put on stack, so I don't think there will be a major slow-down.
Also, to define operator+ for Complex and Real, it is enough if one side of the operator is a user-defined class. The other may well be a built-in type.
If this is not an exercise, then C++ already has a standard <complex> header.

Quote:

---

Real numbers become complex numbers when the second argument of an operator+, or the argument of an operator +=, is a complex number.

---

The second requirement does not make sense. You are saying that adding a Complex to the current Real changes its type. I would think that you should simply forbid adding a Complex to the current Real. Alternatively, discard the concept of a Real as a separate type since in mathematics, the set of real numbers is a subset of the set of complex numbers.

Quote:

---

I have made a type 'Real' as a typedef of 'double', and a type 'Complex' as a class (with all necessary operators). 'Complex' has a one-argument constructor with 'Real', but now I would like to have an operator+, or operator+=, for my 'Real' which converts the real number in a complex number.

---

Declare operator+ as:

Code:

---

Complex operator+(const Complex& lhs, const Complex& rhs);

---

Now, with your Complex constructor that takes a Real, this operator+ will return the sum of a Real and a Complex as a Complex. Likewise, your operator+= will add a Real to the current Complex object.

Quote:

---

Should I make a separate class 'Real' ? I think that this will have a huge impact on performance, since now all my variables will no longer be written directly on the stack, as is the case (if I'm correct) with the primitive types in C++.

---

They will still be on the stack since you do not use dynamic memory allocation.

Quote:

---

Alternatively, discard the concept of a Real as a separate type since in mathematics, the set of real numbers is a subset of the set of complex numbers.

---

The reason why I use two different types is that I want to use them later on as parameters for template classes. For example, the set of real vector spaces is _not_ a subset of the set of complex vector spaces. They both are vector spaces, but parametrized with a field of either real or complex numbers [Simmons: Topology and Modern Analysis, 1963].

But yeah, I think it wouldn't be a bad idea to define a type 'Complex' and derive a type 'Real' to stick to mathematics. I have just been discouraged to use derivations (and moreover, dynamic polymorphism), for performance reasons [Vandevoorde&Josuttis, C++ Templates, 2003].

Quote:

---

If this is not an exercise

---

Of course! What else should I do on a nice, sunny day as today? Trying to implement a mathematical (linear algebra) library which sticks as close as possible to algebra is a great way to learn..

But to stick to my question, albeit more general:
How can I implement a conversion constructor from A to B, if one is of course no derivation of the other and if there is no composition/aggregation?

Quote:

---

The reason why I use two different types is that I want to use them later on as parameters for template classes. For example, the set of real vector spaces is _not_ a subset of the set of complex vector spaces. They both are vector spaces, but parametrized with a field of either real or complex numbers [Simmons: Topology and Modern Analysis, 1963].

---

Yes, in this case they have to be distinct types.

Quote:

---

But yeah, I think it wouldn't be a bad idea to define a type 'Complex' and derive a type 'Real' to stick to mathematics.

---

However, even if you do that, it will not solve the impossible operator+= requirement. You simply cannot have a case where:

Code:

---

Complex x;
Real y; // By inheritance, y is also a Complex object.
y += x; // y is no longer a Real object.

---

Consequently, I think you should simply not provide an operator+= that takes a Complex argument, and also not have a constructor that takes a Complex argument, unless that constructor was declared explicit.

Quote:

---

I have just been discouraged to use derivations (and moreover, dynamic polymorphism), for performance reasons [Vandevoorde&Josuttis,m C++ Templates, 2003].

---

I believe it is not so much the use inheritance as the use of virtual functions (i.e., "dynamic polymorphism") that can be a performance problem. Of course, if used correctly and wisely it may not even be a problem to begin with, since it would be an appropriate solution.

I'd just eliminate Real as a separate class. Add a single argument constructor to the Complex class which sets the real part, and leaves the imaginary part at 0.0.

You could also provide a conversion operator to double, which would just return the real part. There are options for how to deal with the imaginary part. First, you could just ignore it, and hope that the person who is converting to double realizes that data might be lost. Or you could check if the imaginary part is not exactly 0.0 and throw an exception when someone tries to convert a complex to a double.

Quote:

---

How can I implement a conversion constructor from A to B, if one is of course no derivation of the other and if there is no composition/aggregation?

---

That would be done via a conversion function, though it may be better to make the conversion explicit via a toComplex() and/or toReal() function, or by providing the appropriate constructors (which should be explicit so as to prevent unintended conversion, as mentioned in my previous post).

Quote:

---

However, even if you do that, it will not solve the impossible operator+= requirement. You simply cannot have a case where:

Code:

---

Complex x;
Real y; // By inheritance, y is also a Complex object.
y += x; // y is no longer a Real object.

---

---

But this is exactly why I would like to implement a function (cast constructor or other) which changes the type of the object 'y'. So a kind of a 'static_cast<Complex>(y)', which would be possible if 'Real' derives from 'Complex'.

Quote:

---

You could also provide a conversion operator to double, which would just return the real part.

---

This will be a 'friend' function 'real( Complex const&)' or 'imag( Complex const&)'. Converting a complex to a real when the imaginary part is zero might become very tricky: a complex value of a something like ' x + j* _e-214' will not be treated as a real...

Quote:

---

That would be done via a conversion function

---

That's exactly my question: how to do this? I know there are functions like 'type_id' , 'typeof' ,'type_info' but can they also change a type? For example

Code:

---

Real x; // x as real
typeof(x) = Complex; // x now becomes Complex with zero imaginary part
Complex z = x; // assuming no copy constructor can be called due to its 'explicit' declaration

---

That's exactly my question: how to do this?

Code:

---

class A
{
public:
    operator B() const; // Conversion function
};

---

The conversion function to B would return an object of type B. It would be used in any context where an object of type A is casted to type B.

Quote:

---

I know there are functions like 'type_id' , 'typeof' ,'type_info' but can they also change a type?

---

No, RTTI is interested in type information, not type conversion.

Code:

---

Real x; // x as real
typeof(x) = Complex; // x now becomes Complex with zero imaginary part

---

I believe this is something you can't do in C++.

Code:

---

Real x;
Complex z = x;

---

This on the other hand should not cause any problems.

Anyway, what's the point of converting to and from Complex every time it loses or gains the imaginary part? Why not simply work with Complex objects all along?

Quote:

---

Why not simply work with Complex objects all along

---

Since I think that the type of an object should always be the most "low" one, e.g., a 'double' could also be a 'vector' of size one, but I think it is better to keep it a 'double'. Performance and memory consumption are the practical considerations on top of my religious ones: a summation of two 'Real's should be faster than a summation of two 'Complex's, and the former's storage will be less.

You're trying to undermine the concept of type safety.

You could make a RealOrComplex class, that would store either a real, or a complex object as needed. However, the implementation of such an object would take more memory and cycles than just using complex all the time.

Real cannot derive from Complex. It does not fulfill the Liskov Substitution Principle. Or in other words, never use derivation for defining a restriction. (That's also the classic Square from Rectangle example.)
Nor can you use it for defining an extension, actually - deriving Complex from Real is just as wrong.
You should use derivation to go from more abstract to less abstract. Complex and Real are both concrete, so they cannot derive from each other.

Quote:

---

Real cannot derive from Complex. It does not fulfill the Liskov Substitution Principle.

---

Thanks for this explication, I will read more on this principle. I have already struggled psychologically with the idea of derivations, since if 'Real' derives from 'Complex', a one-argument constructor for 'Complex' with 'Real' as argument type would be impossible. Also, a derived class seemed at a first glance similar to a subset, but then functionality can be added which is in contradiction.


But hold on, this is what I just found on Wikipedia as a definition of the Liskov Substitution Principle:

Quote:

---

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

---

This holds for all 'Real' objects when derived from 'Complex' : conjugate( x), imag( x), real( x) and so forth.

It also holds for all 'Complex' objects if derived from 'Real', the functions mentioned above should just be added.


I think that the Liskov Substitution Principle should always be satisfied in derivation hierarchies, but is not decisive for the question whether derivation is the right architecture.

What is the right architecture for the informatics model of a superset/subset structure? Class nesting?

Quote:

---

This holds for all 'Real' objects when derived from 'Complex' : conjugate( x), imag( x), real( x) and so forth.

---

Well, it does depend on what behaviour you provide. For example, Complex might have a member function to get the imaginary portion. That does not make sense for a Real. On the other hand, you could say that Real objects do have an imaginary portion that is 0... but then what's the point of a Real class when Complex will do?

I think the decision on whether to keep everything to Complex or have both Real and Complex depends on your set of vector spaces thing that you are trying to model. If you can model that with just Complex, then it would be simpler (heh, what irony) to just use Complex.

Quote:

---

This holds for all 'Real' objects when derived from 'Complex'

---

Absolutely not. One property of a Complex object would probably be: "It's possible to set the imaginary part to an arbitrary value."
A Real does not have this property, because if the value is anything but 0, it wouldn't be a Real anymore.

Neither does it work the other way round. One very important property of Reals is: "There exists a total order '<' for the entire domain of real numbers."
But less-than is not defined for complex numbers.

It's true that just because the LSP is satisfied it doesn't mean that class derivation is automatically the correct solution. But what does hold is that if the LSP is not satisfied, derivation is definitely not the correct solution.

Shame on me! You're right, I forgot about the ordering '<'.

Mathematically, a subset/superset relation designates an "is a" relation. This "is a" relation is exactly what designates a derivation, as "they" have always told me.
At the same time, a complex number "has" two real numbers, as the functions 'imag( z)' or 'real( z)' should return a real number. I think this simultaneous "is a" and "has a" relation is confusing if not wrong.

"They" are wrong. A derivation requires "is-a", but "is-a" is not sufficient for derivation. The "is-a" of derivation is one of abstraction: a dog "is-a" animal. That's not because dogs are a subset of animals, but because animal is a more abstract concept than dog.

"Works-like-a" is often used in addition to or instead of "is-a" when explaining when to use public derivation. "Works-like-a" obviously more closely matches the crux of the LSP.