<snip>
I believe the form of the constructor is actually:
complex(const T& re = T(), const T& im = T());
I think we need someone to get a rule-book here, because I think you're wrong.
Well, it won't be the first time or the last that I'm wrong.
The "T()" syntax should provide value-initialization, which will be zero for the built-in numeric types. Asking any mathematical type that isdefault-constructible to have said default state be equivalent to zero (or empty set, or some other analog) should be a requirement. (And for such math types, they should have a Boolean conversion where said zero/empty state is the only regular one that maps to False. Math types that do not map to (a subset of) real numbers should have said conversion be explicit.) <snip>
Daryle W.
Daryle, this issue has puzzled me for some time now I guess there are two choices here for a potential complex<T> in boost: 1. complex(const T& re = T(), const T& im = T()); 2. complex(const T& re = T(0), const T& im = T(0)); Let's keep in mind that we are talking about a template parameter that is *not* required to be one of the built-in types float, douuble or long double. It's hard to interpret the right thing to do here. ISO/IEC 14882:2011 specifies a generalized template for complex<T> with the first form of the constructor (the one with T() default parameters). But ISO/IEC14882:2011goes on to explicitly specify the forms of each template specialization for float, double and long double. In addition, ISO/IEC 14882:2011 clearly states that complex<T> for any type other than float, double or long double is not specified. According to ISO/IEC 14882:2011, the constructor for the specialization of complex<float>, for example, is: template<> complex<float>(float re = 0.0F, float im = 0.0F); The input parameters are non-constant and non-references. Furthermore, the default parameters are specified to be 0.0F, not float(). So should a potential Boost.Complex use the default parameter T() or rather T(0)? It may be more "in the spirit" of ISO(IEC 14882:2011 to use T(). On the other hand, writers and users of a specialized type might be confused when all of a sudden complex<user_type> might potentially be creatable with non-zero junk. In the end, there is no right or wrong. It's just up to boost to set a policy here and document it. In my opinion, this should be sorted out in a potential review. Best regards, Chris.