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

Subject: Re: [boost] [complex] Feedback and Potential Review Manager
From: Matthieu Schaller (matthieu.schaller_at_[hidden])
Date: 2012-05-07 19:25:11

>>> but rather the default ctor of the template type.
>>> complex(const T&   re = T(), const T&   im = T());
>>>
>> Do I understand correctly that the default constructor
>> does not set real and imag parts to zero?
> Well, it's appears to be more subtle than we might want
> it to be. ISO/IEC 14882:2011 specifies the T() form for
> the generalized complex template. The language
> specification goes on, however, to specify
> that only float, double and long double are
> valid template parameters for complex.
> And the subsequent template specializations
> for the built-in floating-point numbers have
> default values of 0.0F, 0.0, 0.0L.
>
> For example, as in my other post, the specified
> constructor for float is:
>
> complex(float  re = 0.0F, float  im = 0.0F);
>
> I also believe that the value of, say, the default
> constructor of float is zero. In particular
>
> void do_something()
> {
>    // F1 is initialized to zero.
>    float f1 = float();
>    ...
> }
>
> So ISO/IEC 14882:2011 ensures that all valid uses
> of complex are default initialized to zero. Without
> judgement, this is the spec.
>
> What a potential Boost.Complex should do for
> user-defined types that may potentially default construct
> to non-zero is an open issue.

In my opinion, any sensible number library (aiming at extending 
real/integer numbers) should provide a default constructor that 
initialize the value of the number to 0. It is the behavior that the 
end-user will most probably expect.

There are three options:

(a) Stick to T() and document that the type T should have a default 
constructor building a zero-valued T.
(b) Change to T(0.) and not respect the standard. This does also imply 
that T must have a constructor taking a double as an argument.
(c) Do not initialize the number when the default constructor is called. 
This would allow the allocation of an array of complex<T> without having 
to actually copy numbers. A zero-valued complex number could still be 
built using one of the other constructors.

I would prefer (a) in order to stick to the standard or (c) to allow 
optimized allocations.

For what it's worth, boost::rational does not rely on the default 
constructor of its template type and explicitly calls the constructor of 
the numerator with the value 0 in its default constructor.

By the way, the constructors of boost::rational do not use constant 
references for their arguments. There might be some useless costly 
copies when the type used is not POD.

Regards,

Matthieu

-- 
Matthieu Schaller