Re: [boost] [complex] Feedback and Potential Review Manager

Subject: Re: [boost] [complex] Feedback and Potential Review Manager
From: Daryle Walker (darylew_at_[hidden])
Date: 2012-05-07 10:50:34

> Date: Mon, 30 Apr 2012 17:07:49 +0100
> From: 
Chris
>
> > 3) I disagree with
>
> > explicit complex(const T& re = T(0.), const T& im = T(0.))
> > I
> believe this constructor should be non-explicit.
> > See ISO/IEC 14882:2011, Section 26.4.2.
>
> With which I, myself, disagree. It's funny, because
> even my suggested correction is wrong---again!

Complex numbers are a (strict) super-set of reals, so a real should betransparently convertible to complex.  Explicit constructors are forconstructor input (and, since C++11, input tuples) that are configurationparameters instead of equivalent values.
> I believe the form of the constructor is actually:
> complex(const T& re = T(), const T& im = T());
>
> The default parameters are not initialized to zero,
> but rather to the default constructor of the template type T.
> There is a subtle difference, and one which masks user-error
> in a "too-forgiving" fashion. It's a real pitfall because it makes
> the wrong code seemingly work right and then be break when
> complex is fixed. A long time ago, the man known as STL
> brought this to my attention.

I think we need someone to get a rule-book here, because I think you'rewrong.  The "T()" syntax should provide value-initialization, which will bezero for the built-in numeric types.  Asking any mathematical type that isdefault-constructible to have said default state be equivalent to zero (orempty set, or some other analog) should be a requirement.  (And for suchmath types, they should have a Boolean conversion where said zero/emptystate is the only regular one that maps to False.  Math types that do notmap to (a subset of) real numbers should have said conversion be explicit.)
> But I re-made the same mistake again, and again...

Just researching this, I found out some (all?) versions of MSVC don't dothis right.  They ignore value-semantics and always apply default-semanticshere; leaving built-in numeric types and POD types as random bit buckets.If you're using MSVC, then that may be your problem, which is a compiler bug.
> In a potential review, we should go through the constructors
> meticulously and make sure they are as they should be.

Daryle W.