[Bug libstdc++/12961] New: Problem with generic complex constructor

[Bug libstdc++/12961] New: Problem with generic complex constructor

[Yves dot Renard at gmm dot insa-tlse dot fr]

The constructor for the template class std::complex<flt>
is different as the one for specialized complex classes
std::complex<float> std::complex<double> and std::complex<long double>

The one for the generic template :
complex(const _Tp& = _Tp(), const _Tp & = _Tp());

The one for std::complex<float>
complex(float = 0.0f, float = 0.0f);

When I use qd (a library for quatruple double) and 
std::complex<qd_real>
I cannot initialize that kind of complex with
std::complex<qd_real> x(1)
because the imaginary part is not initialized.

This does not allow me to build completely generic algorithm for my library
GMM++ (see http://www.gmm.insa-tlse.fr/getfem/gmm.html)

-- 
           Summary: Problem with generic complex constructor
           Product: gcc
           Version: 3.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Yves dot Renard at gmm dot insa-tlse dot fr
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12961

[Bug libstdc++/12961] Problem with generic complex constructor

[paolo at gcc dot gnu dot org]

------- Additional Comments From paolo at gcc dot gnu dot org  2003-11-08 14:02 -------
Hi. Could you please provide a small, self-contained code snippet demonstrating
the problem?

Thanks, Paolo.

P.S. I have even tried downloading your library but grepping for 'qd_real' finds
nothing...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12961

[Bug libstdc++/12961] Problem with generic complex constructor

[Yves dot Renard at gmm dot insa-tlse dot fr]

------- Additional Comments From Yves dot Renard at gmm dot insa-tlse dot fr  2003-11-10 06:54 -------
(In reply to comment #1)
> Hi. Could you please provide a small, self-contained code snippet demonstrating
> the problem?
> 
> Thanks, Paolo.
> 
> P.S. I have even tried downloading your library but grepping for 'qd_real' finds
> nothing...
QD is a library for double-double and quadruple-double you will find at the
following address:
http://www.nersc.gov/~dhb/mpdist/mpdist.html


But I think, the problem is that the template definition should be
complex(const _Tp& = _Tp(), const _Tp & = _Tp(0));
(this was the case in preceding version of the S.T.L.)
or better, there should be two constructors
One to initialize a complex with a real, or two real, with an initialization
to zero of the imaginary part:
complex(const _Tp&, const _Tp & = _Tp(0));
And one default constructor which does not initialize anything:
complex()



The problem with QD is that the default constructor does not initialize the
number to zero. Then when I declare

std::complex<qd_real> a(1);

The real part is initialized to 1 but the imaginary part is not initialized.
So a will be equal to something as (1.0 + 3.354434534i)
What is stange is that if the template definition would be applied to float,
double or long double, the problem would be the same. Fortunately, a specialization
is made. But, even for those types, I am not convince that the constructor:
complex(float = 0.0f, float = 0.0f);
is very convenient, because it implies that a complex is alway at least initialized
zero (lost of comp. time). I think that there should be two constructors also
for complex<float>, complex<double> and complex<long double> (i.e. one additional 
default constructor which does not do anything).













-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12961

[Bug libstdc++/12961] Problem with generic complex constructor

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-11-10 07:14 -------
Sorry but the standard says to do from 26.2.2:
complex(const T& re = T(), const T& im= T()); 
and float() is the same as float(0) (likewise for double and long double.
Sorry but the standard says othereise for all of your constructors.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12961

[Bug libstdc++/12961] Problem with generic complex constructor

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2003-11-10 09:45 -------
Subject: Re:  Problem with generic complex constructor

"Yves dot Renard at gmm dot insa-tlse dot fr" <gcc-bugzilla@gcc.gnu.org> writes:

| But I think, the problem is that the template definition should be
| complex(const _Tp& = _Tp(), const _Tp & = _Tp(0));

I can't understand that "should".  If your sscalar type behaves in
such a way that T() is different from T(0), then you're in trouble and
that isn't the library's fault.  See the standard requirement on
numeric types.

[...]

| The problem with QD is that the default constructor does not initialize the
| number to zero.

That is a flaw design in QD then.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12961

[Bug libstdc++/12961] Problem with generic complex constructor

[Yves dot Renard at gmm dot insa-tlse dot fr]

------- Additional Comments From Yves dot Renard at gmm dot insa-tlse dot fr  2003-11-10 11:18 -------
(In reply to comment #3 and  #4)

Ok, this means that 
float x;
does not initialize x, but
float x = float();
does initialize x to zero.

and  this is the same between
float v[56]  // does not initialize v
and
std::vector<float> v(56); // does initialize each component of v


This is a little bit strange to me but I suppose this is the norm.

Anyway, thank you very much for the information.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12961