Boost logo

Boost :

From: Pavel Kuznetsov (pavel_at_[hidden])
Date: 2004-08-23 14:48:04


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, 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) );
  }

where value_type is value_type of corresponding iterator. And of
course it is possible to avoid creating proxy object when iterator's
operator* returns reference, not value...

-- 
Pavel Kuznetsov
MetaCommunications Engineering
http://www.meta-comm.com/engineering

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