[C++-sig] Re: indexing_v2 status update

[Raoul Gough]

David Abrahams <dave at boost-consulting.com> writes:

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> ::boost::python::indexing::iterator_traits. It provides some
typedefs,
>> has_copyable_iter, is_reorderable and index_style, although
>
>This describes traits of containers, right?  Calling something
>iterator_traits which doesn't describe traits of iterators is very
>confusing.

Well, I'm not *so* sure it's wrong. It's supposed to describe features
that can be deduced from properties of the iterator, and since it's in
the indexing:: namespace, I didn't think the name was too bad.
Unfortunately, it looks like the only feature it's guaranteed to
determine reliably is has_copyable_iter. This leaves a problem for
iterator_range, where the iterator is all that there is to go on, and I
suppose it currently breaks on things like
iterator_range<std::map<...>::iterator>.

>> However, it seems ok for
>> containers that are normally reorderable but have top-level const
>> qualification. i.e. it looks like
>>
>> is_const<remove_reference<container::const_iterator::reference> >
>>
>> always gives the "right" answer for has_mutable_ref and therefore
>> is_reorderable as well.
>
>Ouch!  That seems like it has to be pure luck.  After all, for
>std::set, const_iterator == iterator is legal, and it's easy to
>imagine a set<T> iterator which returns T const& from dereference.
>
>Further, as I've been trying to tell you, the iterator's "reference"
>type is currently not constrained by the standard in many cases.  Much
>better to use the same trick used in is_lvalue_iterator.

I understand what you've been saying about the reference type, and all
I'm saying is that it works in practice for const containters on all
the compilers I've tried so far. Things like std::set and std::map
require extra handling anyway, because we actually need is_assignable,
not merely is_lvalue or is_mutable_ref.

Anyway, I think this particular issue will disappear once I move to
bitsets or mpl::set, since it would simply be a question of maksing off
certain features if the container is const qualified. I'll have a
better look at mpl::set when I get a chance (hopefully by next week
sometime). I've been considering whether it would be possible to
provide an abstraction that would allow a change of implementation
between bitsets or mpl::set without affecting client code.

Regards,
Raoul Gough.

________________________________________________________________________
BT Yahoo! Broadband - Save £80 when you order online today. Hurry! Offer ends 21st December 2003. The way the internet was meant to be. http://uk.rd.yahoo.com/evt=21064/*http://btyahoo.yahoo.co.uk