Re: [boost] [range] Problem with adaptors::map_keys

Subject: Re: [boost] [range] Problem with adaptors::map_keys
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-11-28 11:11:20

On 11/28/2010 5:33 AM, Alexander Fokin wrote:
> I'm having some troubles using adaptors::map_keys with custom
> iterators over Qt associative containers.
>
> The problem with Qt associative containers is that they provide
> iterators over a set of values, not over a set of key-value pairs. I
> have worked that around by introducing boost range bindings:
> http://codepad.org/xnZrpZ5i

Three things:
- value_type should just be pair< Key, T > (no reference or const 
qualifications on Key or T)
- reference should be pair< Key const &, T& >, with T possibly 
const-qualified (as you've done)
- you can (if you want) use iterator_adaptor instead of iterator_facade 
to automatically get a correct equal, increment, and decrement.

> However, when these binding are used, the following code produces a
> compilation error:
>
> BOOST_FOREACH(auto pair, (QMap<int, int>()) | boost::adaptors::map_keys);
>
> Everything works fine if the code of boost::range_detail::select_first
> is slightly modified. You'll find the patch attached.
>
> I believe it's a problem in boost range, but I may be wrong, so I need
> some expert help here.

There shouldn't be a difference between range_value<R>::type and 
range_value< R const >::type, so I'd question the correctness of this 
fix.  It might work for you because your value_type's for your mutable 
iterators and const iterators are different, but like I inferred above, 
they should be the same.

Looking at the code in <boost/range/adaptor/map.hpp>, it looks like some 
instances of range_value should be replaced with range_reference, e.g., 
the parameter to select_first< Map >::operator() might be better as 
range_reference< const Map >::type rather than range_value< Map >::type 
const &.  (Keep in mind I'm looking at version 1.43, so things may have 
changed since.)  You might want to file a trac ticket and see what the 
maintainer (Neil Groves?) says, or wait and see if others opine on this 
mailing list...

- Jeff