|
Boost : |
From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-04-05 11:10:35
On 5 Apr 2001 nbecker_at_[hidden] wrote:
nbecke>
nbecke> One problem I've encountered is what to do with:
nbecke>
nbecke> Reference dereference(type<Reference>, const BaseIterator& i) const
nbecke>
nbecke> For example, if you are adapting a complex container extracting the
nbecke> real part, you can't get a reference to it. I guess the only choice
nbecke> would be to return a proxy object that overloads assignment?
Well, if you could get at a reference to the real part, then you could use
the projection iterator adaptor. But, as you point out below, you can't.
So you're stuck with the ugly proxy thing (you'd be stuck with this
whether or not you used iterator adaptor). You'll need to use the proxy
object as the Reference type of the iterator adaptor. And you'll be stuck
with using input_iterator_tag as the iterator_category :(
(yet another example of the need for my new iterator categories and
concepts)
nbecke> This brings us to another point. I believe it's a mistake that real()
nbecke> and imag() of complex don't return a reference. This makes a lot of
nbecke> things (like this current example) a lot harder.
nbecke>
nbecke> The argument I've heard is that complex should be an opaque type to
nbecke> allow for alternative data representations, such as polar.
nbecke>
nbecke> IMHO, no one is ever going to use this flexibility, and the price for
nbecke> it is too high. Instead, I believe we should accept that complex is
nbecke> defined as a cartesian pair.
nbecke>
nbecke> Another argument for this is the conversion of old code (C or FORTRAN)
nbecke> which generally expect assignments like:
nbecke>
nbecke> z.real = blah
Yeah, this is a bummer.
Ciao,
Jeremy
----------------------------------------------------------------------
Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
Ph.D. Candidate email: jsiek_at_[hidden]
Univ. of Notre Dame work phone: (219) 631-3906
----------------------------------------------------------------------
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk