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

[lostbits]

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
private:
    double creal;
    double cimag;
public:
    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}; }

#endif

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 
gnu.org/software/gslip to see an approach.

art