Re: std::complex design (Was: N-Dimensional array library submission...)

From: Ralf W. Grosse-Kunstleve (rwgk_at_[hidden])
Date: 2002-01-10 17:27:58

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> > If std::complex was simply derived from boost::array<T, 2>,
> > portable conversions would be immediately possible, and you
> > could still provide iterators where they make sense.
> >
> > To put it in more general terms: encapsulation is a great
> > idea, but can backfire if overused (as in std::complex, IMO).
> 
> I'm afraid that wouldn't work for you. Since complex<T> is a non-POD type
> for example, the compiler is not required to make it possible to portably
> convert it to/from a T* via reinterpret_cast
> 
> What's needed here is a loosening of the restrictions on what constitutes a
> POD.
> 
> If you write up an email describing the real-world problems for me, I'd be
> happy to post to the C++ extensions reflector.

Points:

- The real world problem is indeed compatibility with
  existing C or FORTRAN code.

- For in-place FFT's it is only necessary to cast a pointer
  to the beginning of a vector (in the general sense) of
  std::complex to a pointer to the beginning of a
  vector of real numbers (e.g. float or double).
  I.e., essentially memory is reused for different types
  without actually caring about the conversions between
  the types. Using reinterpret_cast<> for this purpose
  seems perfectly OK.

Regarding compatibility with existing C code:
  C does not have a complex type. FFTW (e.g.) introduces
  its own type. I guess it is next to impossible to ensure
  portable conversions from std::complex to custom types
  like FFTW's.

Regarding compatibility with existing FORTRAN code:
  AFAIK FORTRAN COMPLEX are by definition stored as
  consecutive real values, real part first, imaginary
  part second. Here it would help if std::complex
  was derived from boost::array<T, 2>.

My proposal was (message 22021 in this group):

    template <class T> class complex : public boost::array<T, 2> {
        //...
    };

    complex<double> c;
    double* a = c.elems;

No cast required.

Not even for reusing memory in an in-place FFT procedure.

This would work portably with FORTRAN code, and, more
importantly, code that is ported from FORTRAN to C++ (such
as my fftbx posted here earlier).

My proposal is compatible with all existing implementations
of std::complex that I know about, but formalizes
assumptions that are commonly made in practice (this should
include the assumption that the complex value is internally
represented as a real and an imaginary part, as opposed to,
e.g. an amplitude and an angle).

It does not, however (as I realize now), improve
portability when using C code such as FFTW from C++. (But
then again, it would be easy to modify the C header file to
derive the custom type from std::complex if compiled with
C++).

Ralf

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/