Is there any class that can promote a type to the complex type?
Hi,
To promote a type, no matter complex or not, to the complex type can
be done by the following code. RET would give me a complex type. The
code is simple. I'm wonder if boost has already supplied such facility
so that I don't have to include the following snippet in my own code.
Thanks,
Peng
#include <complex>
#include <iostream>
template <typename T>
struct convert {
typedef std::complex<T> RET;
};
template <typename T>
struct convert
AMDG Peng Yu wrote:
I'm wonder if boost has already supplied such facility so that I don't have to include the following snippet in my own code.
<snip> Not to my knowledge. In Christ, Steven Watanabe
Steven Watanabe a écrit :
Not to my knowledge.
I'll take this opportunity to ask the follwoing : would be a properly designed complex class be considered as a potential inclusion to boost (along octonion adn quaternion) ? In everyday life, using std::complex is sometimes cumbersome as some basic operations or conevrtion are lacking.
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
AMDG Joel FALCOU wrote:
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>&);
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)
The operators overloads are intrusive, too, since they ought to be found by ADL and its illegal to add functions to namespace std.
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
Isn't that what the std::complex default constructor does? It does and I think it's a bad practice.
explicit complex(const complex<double>&); explicit complex(const complex<long double>&);
Why are they explicit ? Where is the risk to have non-explicit destructor ?
template
AMDG Joel FALCOU wrote:
Isn't that what the std::complex default constructor does?
It does and I think it's a bad practice.
Why?
they are implicit for float -> double or long double and double to long double. In other words, the constructors are explicit when an implicit conversion would normally generate a warning for the value type.
Yes. We ran into this with the Units library. If two different class templates define such overloads, then trying to add them is ambiguous.
If it did, shouldn't SFINAE make the cut by restrictng U to types that verify : boost::is_floating_points<U>::value == true ?
Ok. In Christ, Steven Watanabe
participants (4)
-
Joel Falcou -
Joel FALCOU
-
Peng Yu -
Steven Watanabe