|
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