"Pavel Kuznetsov" <pavel@despammed.com> 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