[boost] Re: boost::dereferenceable<>::operator->() problem

From: David Abrahams (dave_at_[hidden])
Date: 2004-08-23 15:53:04

"Pavel Kuznetsov" <pavel_at_[hidden]> writes:

> Recently two of our developers encountered the same problem with
> boost::dereferenceable<>::operator->().
>
> There were an iterator which returned value_type from its operator*,
> not value_type&:
>
>   value_type operator*() const;
>
> And it was inherited from boost::random_access_iterator_helper, 

A standard-conforming random access iterator must return value_type&
from its operator*.

> which
> in turn is indirectly inherited from boost::dereferenceable. Since
> our iterator class template did not have its own operator->, one from
> boost::dereferenceable<> was inherited. And it is defined as follows:
>
>    P operator->() const
>    {
>      return &*static_cast<const T&>(*this);
>    }
>
> where P is pointer to value_type of corresponding iterator.
>
> Both of the compilers which we use (MSVC 6.0 and CodeWarrior) compile
> this code without any errors (though at least one of them did gave
> a warning). That lead to operator-> returning addres of a temporary
> object.
>
> What do you think about modifying operator-> so that it would be
> permissive to iterators for which operator* gives rvalue?
>
> E.g. this way:
>
>   struct address_of_proxy
>   {
>     value_type value;
>     address_of_proxy( value_type const& v ) : value( v ) { }
>     operator value_type const*() const { return &value; }
>     value_type const* operator->() const { return &value; }
>   };
>
>   address_of_proxy operator->() const
>   {
>     return address_of_proxy( *static_cast<const T&>(*this) );
>   }

I don't think we should pump up these old helper templates any more.
Can you say "iterator_facade?"

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com