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. - automatic conversion between complex of different base types 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>&)' 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. 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>). On a side note, some other improvements can be added : - a imaginary<T> class is a possible addition (as long as complex and imaginary interacts together correctly) for some computation. It's only a matter of sparing 4-10 cycles here and there on basic operations. - meta-function that computes types related to complex<T> (as suggested by the original author) like T<->complex<T>, complex types promotions, etc ... Anyway, not sure it warrants a library by itself but I feel those small additions can be interesting. -- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France