is it safe to access a complex<double> array as a double array oftwice the length?

[huili80]

Like in the following. Though it gives the expected result with
gcc4.0, is it really safe to do that?
What if it's not double but some non-POD type?

-----------------------------------------
#include <complex>
#include <iostream>
#include <iterator>

int main()
{
using namespace std;

const size_t n = 5;
complex<double> ca[n];
double* dp = reinterpret_cast<double*>(ca);

for (size_t i = 0; i < 2*n; ++i )
dp = i;

copy(&ca[0],&ca[n],ostream_iterator<complex<double> >(cout,", "));
cout << endl;

return 0;
}

 

[Gianni Mariani]

Like in the following. Though it gives the expected result with
gcc4.0, is it really safe to do that?

No. Not safe.

What if it's not double but some non-POD type?

double *is* a POD type. complex<T> is not a POD type.

It's not guaranteed to work. It may work on your particular
implementation.

 

[James Kanze]

On Jun 26, 2:04 pm, (e-mail address removed) wrote:

No. Not safe.
Officially.

double *is* a POD type. complex<T> is not a POD type.

I think he was asking about something like complex< BigNumber >.

Of course, "The effect of instantiating the template complex for
any type other than float, double, or long double is
unspecified" (§26.3), so the question is moot.

It's not guaranteed to work. It may work on your particular
implementation.

There are in fact a number of very strong motiviations for an
implementation to make it work. It's guaranteed in Fortran, and
as an implementer, you want your complex to be compatible with
those of Fortran. In practice, I think you might actually be
able to risk it (but *only* for complex<float> and
complex<double>).

(I'm presuming that the reason the poster wants to do this is in
order to interface with some legacy code. Otherwise, I'd
consider it very bad practice, even if it were formally
guaranteed.)

 

[Christopher Dearlove]

In practice, I think you might actually be
able to risk it (but *only* for complex<float> and
complex<double>).

What happened to n1589? It's listed as part of "the inspiration or history
behind
the active or accepted proposals" in n2566, but I can't see any sign of it
in n2606.

Right now I don't need it. But (for Fortran interface) I have needed it in
the
past and took the risk indicated (with a reinterpret_cast) - of course
testing
it on the system on which it was used and documenting it. But that's a poor
substitute for a portable way to do it (which would be without
reinterpret_cast
too).

 

[Greg Herlihy]

Like in the following. Though it gives the expected result with
gcc4.0, is it really safe to do that?

Using a reinterpret_cast in a program is almost always a red flag -
and should be interpreted as a warning that the code - if not unsafe -
is probably fragile.

#include <complex>
#include <iostream>
#include <iterator>

int main()
{
        using namespace std;

        const size_t n = 5;
        complex<double>  ca[n];
        double* dp = reinterpret_cast<double*>(ca);

        for (size_t i = 0; i < 2*n; ++i )
                dp = i;
}

Why not initialize the array of complex numbers in the ordinary (and
safe) way:

for (size_t i = 0; i < n; ++i )
ca = complex<double>(i, i);

Greg

 

[James Kanze]

Like in the following. Though it gives the expected result
with gcc4.0, is it really safe to do that?

Pragmatically, I think yes, although it's not something I'd like
to see in code unless absolutely necessary. (Typically, I'd see
it being used to cast the address of an array of complex to a
double* in order to pass it to some legacy code. Or Fortran.
Or C.)

What if it's not double but some non-POD type?

What if what isn't double? std::complex is defined for float,
double and long double, and that's it. Anything beyond that is
implementation defined, if it's defined at all.