Boost logo

Boost :

From: nbecker_at_[hidden]
Date: 2002-02-22 08:01:44


>>>>> "Gabriel" == Gabriel Dos Reis <Gabriel.Dos-Reis_at_[hidden]> writes:

    Gabriel> nbecker_at_[hidden] writes:
    Gabriel> | I totally agree that it would be much easier to port legacy code if
    Gabriel> | your could say:
    Gabriel> |
    Gabriel> | real(z) = x;
    Gabriel> |
    Gabriel> | However, I should point out that it is easy to make a proxy class that
    Gabriel> | does just this.

    Gabriel> Whether it is easy to make a proxy class for that doesn't suppress the
    Gabriel> problem. In fact, there is no way one could make a modifiable lvalue out
    Gabriel> of real(z), that was my point.

Let me make 2 points:

1) I completely agree that the design of complex, which disallows
   direct access to real and imag, is a mistake. real() and imag()
   should return a ref. I argued this before, but I got responses to
   the effect that someone may want to represent complex numbers as
   mag, phase, etc. Personally, I find this argument unconvincing.

2) I don't understand why you say you can't make a modifiable lvalue.
   What about this:

#include <complex>

using std::complex;

template<typename flt>
class cmplx;

namespace {
template<typename flt>
class real_proxy {
  cmplx<flt>& z;
public:
  real_proxy (cmplx<flt>& _z) : z (_z) {}
  void operator=(flt x) {
    z = cmplx<flt>(x, imag (z));
  }
  operator flt () { return static_cast< complex<flt> > (z).real(); }
};

template<typename flt>
class imag_proxy {
  cmplx<flt>& z;
public:
  imag_proxy (cmplx<flt>& _z) : z (_z) {}
  void operator=(flt x) {
    z = cmplx<flt>(real (z), x);
  }
  operator flt () { return static_cast< complex<flt> > (z).imag(); }
};
};
template<typename flt>
class cmplx : public complex<flt> {
public:
  cmplx (flt x, flt y) : complex<flt> (x, y) {}
  real_proxy<flt> real () { return real_proxy<flt> (*this); }
};

template<typename flt>
real_proxy<flt> real (cmplx<flt>& z) {
  return z.real();
}


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk