[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] Why are standard (*, +, etc) operators not overloaded for

From: lostbits
Subject: Re: [Help-gsl] Why are standard (*, +, etc) operators not overloaded for complex numbers in C++
Date: Sun, 28 Jan 2018 13:34:17 -0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 1/28/2018 10:01 AM, John D Lamb wrote:
On 27/01/18 19:38, Vincent Vandalon wrote:
Dear All,

I am curious why the standard binary operators are not overloaded for the
gsl_complex type in C++; I presume this overloading is omitted
intentionally (since you can quickly write them yourself). Was the choice
to omit overloaded operators mainly driven by the desire to avoid
accidentally/non-explicit casting of a built-in type to gsl_complex?
Presumably because gsl is written in C.

I don’t think C has a complex type. In any case the C++ complex type seems to be difficult to make compatible with the gsl representation while maintaining the original code in C.

I realise it is possible to do some sort of conversion/casting in C++. But this is not likely efficient.

Operator overloading can be very efficient. To wit:
#ifdef COMPLEX_H
#define COMPLEX_H
class Complex {                  // example 1
    double creal;
    double cimag;
    Complex(double real, double imag): creal(real), cimag(imag) {}
    inline double imag() } return cimag; }
    inline double real() { return ccreal;}
    Complex& operator+(Complex y) {return Complex(y.real() + creal, y.imag() + cimag);}
    Complex& operator+(double  y) {return Complex(y + creal, cimag);
    //  and so on

Complex& operator+(double y, Complex x) { return Complex(x.real() + y, x.imag(); }

typedef struct {                 // example 2
                double creal;
                double cimag;} complex;  // this is an example only -- C++ has a complex type

complex& operator+(complex x, complex y) { return complex{x.creal + y.creal, x.cimag + y.cimag}; }


With all functions inline. The inline nature of the functions reduce overhead by eliminating the function call and allows the compiler to optimize the expression itself. The end result is a performance profile similar to a built-in operation.

And the operator overloading can be extended to the remaining arithmetic functions (-, *, /} with equal ease.

If the case against operator overloading is efficiency, then I think that that can be dismissed. This doesn't mean that there aren't other valid reasons for not extending the C functions into the C++ world. As for example, here, In example 1 I have made the complex type a class and implemented the add operator by adding two objects from the class. Example 2 shows a non-object oriented approach.

Both the Complex and complex internals can be made conformant with the existing approaches in gsl (with, perhaps, some issues not discussed here).  I've forgotten how to do casting. Look at the code in to see an approach.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]