AMDG Joel FALCOU wrote:
What exactly is missing? Is there any particular reason it can't be added as free functions?
Well, basically :
- a large number of classic mathematic functions. - a real default constructor. Initialising complex<T> to (T(0),T(0)) seems redundant.
Isn't that what the std::complex default constructor does?
- automatic conversion between complex of different base types
In complex<float>: explicit complex(const complex<double>&); explicit complex(const complex<long double>&);
and overload support for complex/scalar interaction e.g :
int main() { complex<float> a(1,1); complex<double> b(2,2); complex<float> c; complex<int> d(2,2);
complex<float> e(d); // Error : error: no matching function for call // to 'complex<float>::complex(complex<int>&)'
The standard states that "The effect of instantiating the template complex for any type other than float, double or long double is unspecified." (26.2)
c = a+3.f; // works c = a+3; // Error : no match for 'operator+' in 'a + 3' c = a+b; // Error : no match for 'operator+' in 'a + b' }
As you said, most of them can be fixed through free function ( the operator overload, the additional math function) and that's what I did for some of my code, but the lack of proper constructors and operator= seems to need some intrusive code fixes.
The operators overloads are intrusive, too, since they ought to be found by ADL and its illegal to add functions to namespace std.
Maybe it's just me that have strange request or write strange code, but it feels strange and counterintutive that the std::complex genericiy is not generic enough : I don't see what's different between adding a float and a double (returning a double) and adding a complex of float and a complex of double (returning a complex<double>).
I think that you are correct about operators on two complex types. However, it is probably not a good idea to have operator overloads like the following template<class T, class U> complex<T> operator+(const U& lhs, const complex<T>& rhs); because they can cause ambiguities. In Christ, Steven Watanabe