$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.
Cheers, Phil.