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

[David Abrahams]

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>
>>> David Abrahams <dave at boost-consulting.com> writes:
>>>
> [snip]
>>>> I just mean that iterator_traits<I>::value_type is never a const type
>>>> for any valid iterator I.
>>>
>>> If the container is const qualified then begin() and end() return
>>> const_iterators, so the container_traits have to typedef the right
>>> iterator type. I also try to use the iterator information for
>>> is_reorderable (via has_mutable_ref):
>>>
>>>   template<typename Container, typename ValueTraits = detail::no_override>
>>>   struct base_container_traits
>>>     : public ::boost::python::indexing::iterator_traits<
>>>         BOOST_DEDUCED_TYPENAME mpl::if_<
>>>           is_const<Container>,
>>>           BOOST_DEDUCED_TYPENAME Container::const_iterator,
>>>           BOOST_DEDUCED_TYPENAME Container::iterator
>>>         >::type
>>>       >
>>>
>>> Of course, top-level const also affects has_insert and so on, but
>>> those aren't related to the iterator type.
>>
>> I still don't see what *that* has to do with the const-ness of an
>> iterator's value_type.  I can't make the connection.
>
> Oh, right. The iterator_traits base class

What iterator_traits are we talking about here?  The one I know about
doesn't know anything about "reorderability".

>  tries to figure out a value for is_reorderable. From what you're
> saying, this is doomed to failure because (a) the iterator reference
> type is unpredictable and (b) the iterator value_type is the same in
> both const_iterator and iterator.

And regardless none of that tells you whether it's assignable.

> [snip]
>> That's why I was suggesting a capabilities should be indicated as a
>> sequence of tag types.
>
> Yes, I now see how this would address the same issue. The problem I
> see with using mpl::set or such like is the cost/benefit trade off. I
> don't see any way to factor out the Python method registration code
> (the class_<>::def calls) into the tag types, since they don't
> represent that level of decision - they only describe container
> abilities, which in some cases must be combined before deciding what
> methods to register. 

In that case all they offer is "infinite" extensibility.

> I don't see them ever representing more than boolean values, in
> which case there's not much benefit in applying all that mpl
> machinery. As for costs, maybe it's just because I haven't used
> mpl::set before, but it seems to me to add complexity.

It does.

> I imagine it introduces additional compile-time costs, big debugging
> symbols and maybe insanely long error messages if something breaks
> (although I get them already, of course).

Yeah, what's one more? ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com