Subject: Re: [boost] [iterator] iterator_facade reference type problem
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2010-01-14 12:47:46
Phil Endecott wrote:
> But what do I do about the reference type? I can't use std::pair<const
> KEY,VALUE>& because I'm not storing the keys and values in that way.
> It's almost possible to use std::pair<KEY,VALUE> for a const_iterator,
> but not if you want to allow the user to change the value through the
> reference. What I think I want to use is std::pair<KEY,VALUE&> i.e.
> the key is returned by value and only the value is returned by
> reference. But when I try this I get various cryptic errors about
> references to references and mpl things.
I've done some more experiments, and it seems to work with
std::pair<const KEY, value&> if i write (*iter).second rather than iter->second.
Looking at the iterator_facade source, operator-> calls operator* and
passes the result to operator_arrow_result::make(). This takes its
address and, because std::pair<const KEY,VALUE&> is not a reference, it
tries to convert it to operator_arrow_proxy<...>. This fails because
std::pair<const KEY,VALUE&> is not convertible to std::pair<KEY,VALUE>.
I think I just want operator-> to return a pointer to my reference
type, but the operator_arrow_result stuff is trying to do something
more complicated. In what case is the operator_arrow_proxy useful? Is
there some way to get what I want using iterator_facade?
(Thanks to er for the comments about zip_iterator. It's interesting
that zip_iterator uses iterator_facade internally and doesn't appear to
do anything special to avoid this problem. Thanks also to Jeffrey for
the comments about std::pair's deficiencies wrt references; I think
that by fixing that I could make pair<A,B&> convertible to pair<A,B>
and get the code to compile, but it would still be broken due to a
reference to a temporary.)
BTW I have been testing with an oldish version of Boost, but I've
looked at the source in svn and it doesn't seem to have changed much.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk