Re: [boost] problems with iterator_adaptor after update to 1_38_0

Subject: Re: [boost] problems with iterator_adaptor after update to 1_38_0
From: David Abrahams (dave_at_[hidden])
Date: 2009-02-13 17:11:55

on Fri Feb 13 2009, Oliver Kullmann <O.Kullmann-AT-swansea.ac.uk> wrote:

> Hello,
>
> in the process of updating from 1_34_1 to 1_38_0 I get a
> lot of compiler errors all related to boost/iterator/iterator_adaptor.hpp;
> it's quite some time ago that I've written the code, and the compiler
> messages are cryptic as ever (using gcc version 4.12.0).
>
> The error messages all look like

> /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Boost/1_38_0+4.1.2/include/boost/iterator/iterator_adaptor.hpp:358:
> error: no match for ‘operator-’ in ‘((const
> boost::iterator_adaptor<boost::transform_iterator<FunctionHandling::First<std::pair<const
> OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >,
> std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries,
> OKlib::SATCompetition::SetResultNodesP*> >, boost::use_default, boost::use_default>,
> std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries,
> OKlib::SATCompetition::SetResultNodesP*> >, const OKlib::SATCompetition::SuperSeries,
<snip>
> boost::use_default>::m_iterator’
> /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_bvector.h:182:
> note: candidates are: ptrdiff_t std::operator-(const std::_Bit_iterator_base&, const
> std::_Bit_iterator_base&)
>
> I believe there was a discussion on the boost iterator library lately,
> but I don't think there was a clear outcome. 

Did it have anything to do with your error?

One thing that comes to mind is that you seem to be working with a
vector<bool>, whose iterators are not truly random access iterators even
though they support operator- because *p doesn't return a real
reference.  But that's just a wild guess.

> So perhaps somebody, just
> be seeing this, can guess what the problem could be.
>
> It is not yet clear to me where the above error really comes from (some templates and
> some macros are in
> the way), but perhaps something doesn't work with the following convenience adaptors:
>
>   template <class Range>
>   struct RangeFirstConst {
>     typedef typename boost::range_const_iterator<Range>::type iterator;
>     typedef typename IteratorFirst<iterator>::type iterator_first;
>     typedef boost::iterator_range<iterator_first> type;
>   };
>   template <class Range>
>   struct RangeFirstMutable {
>     typedef typename boost::range_iterator<Range>::type iterator;
>     typedef typename IteratorFirstMutable<iterator>::type iterator_first;
>     typedef boost::iterator_range<iterator_first> type;
>   };
>
>   template <class Range>
>   typename RangeFirstConst<Range>::type range_first(const Range& r) {
>     typedef RangeFirstConst<Range> range_first_const;
>     typedef typename range_first_const::type range;
>     typedef typename range_first_const::iterator_first iterator;
>     using boost::begin;
>     using boost::end;
>     return range(iterator(begin(r)), iterator(end(r)));
>   }
>   template <class Range>
>   typename RangeFirstMutable<Range>::type range_first(Range& r) {
>     typedef RangeFirstMutable<Range> range_first_mutable;
>     typedef typename range_first_mutable::type range;
>     typedef typename range_first_mutable::iterator_first iterator;
>     using boost::begin;
>     using boost::end;
>     return range(iterator(begin(r)), iterator(end(r)));
>   }
>
> range_first(range) is supposed to take a range over pairs, and return a range
> of the first components of the pairs.
>
> Would be glad about any comments.

Well, I dunno, but I wouldn't be surprised if, since you're using the
Range library, this error is reflective of a change in semantics in that
library.  We did have a few recently.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com