Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-09 10:53:32


----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>

> From: "Jeremy Siek" <jsiek_at_[hidden]>
> > The boost/iterator_adaptors.hpp header currently has a local macro for
> > this named BOOST_RELOPS_AMBIGUITY_BUG. We could move this into config.
> > Also, whoever fixes shared_ptr and weak_ptr may want to look at how the
> > workaround was accomplished for iterator_adaptor.
>
> There's a much easier fix, just define
>
> template<typename T> inline bool operator!=(shared_ptr<T> const & a,
> shared_ptr<T> const & b)
> {
> return a.get() != b.get();
> }

Don't you really want a function template which compares arbitrary
shared_ptr<T>, shared_ptr<U> by comparing the count objects, instead?

> or, in your case,
>
> template <class Iterator, class Policies, class Value,
> class Reference, class Pointer,
> class Category, class Distance>
> inline bool
> operator!=(
> const
>
iterator_adaptor<Iterator,Policies,Value,Reference,Pointer,Category,Distance
> >& x,
> const
>
iterator_adaptor<Iterator,Policies,Value,Reference,Pointer,Category,Distance
> >& y);
>
>
> Partial ordering takes care of the rest.

I don't think so. The above operator doesn't allow const_/non-const_
iterator interoperability. Or are you suggesting that simply *adding* this
definition is enough to avoid the problem. That would make plenty of sense.

Hmm, Jeremy, does this allow a massive cleanup of that workaround in
iterator_adaptors?

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk