Re: complex __real__ and __imag__ as lvalues

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Richard Henderson <rth@redhat.com> writes:

| On Sat, Apr 10, 2004 at 01:32:52AM +0200, Gabriel Dos Reis wrote:
| > I would say it is unavoidable.  The alternative is to use ugly
| > reinterpret_cast<>; semantically I don't see what that changes.
| 
| You've given no information.  In what instance are you 
| needing to take the address of a complex value element?

   1)
   Suppose I have an array of N "T __complex__". It is nothing but an
   array of 2 * T.  From abstraction point of view, depending on the
   particular computation, it is useful to be able to view the array
   elements either as complex numbers or just simple Ts.  Popular,
   efficient, FFT implementations just do that.
   That view is guaranteed by the C standard and is a portable way to
   communicate data between C and C++ programs.  Since every element of
   the "array of 2*N Ts" is individually addressable and is most
   certainly a component of a complex number element of the array, that
   component becomes adressable.


   2)
     
   struct C {
      double complex z;

     double& real() { return *(double*)&z; }                    // #1
     double& imag() { return *((double*)&z + 1); }

     const double& real() const { return & __real__ z; }        // #3         
     const double& imag() const { return & __imag__ z; }
   };

  What do we gain with banning #3 that justifies the ugly cast #1 -- that
  actually distracts from the well-defined operation being conducted,
  namely access the first (resp. second part) of a this complex number?

  The syntax #3 is clearer and says what is going on.

-- Gaby