[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:
>
>> 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 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.

[snip]
>> Changing subjects, I have thought of a good reason for using bitflags
>> instead of separate "has_this" or "has_that" static bool consts. 
>
> I wasn't suggesting that you use static bool consts.

That's what I have at the moment though, and I'm still wondering about
whether to change it or not.

>
>> When adding new features, requiring a new constant
>> (e.g. "is_serializable") would break any existing ContainerTraits
>> implementations that don't have it. Adding a new bitflag value would
>> not break anything, since older ContainerTraits simply wouldn't ever
>> set the flag (and wouldn't get the new feature).
>
> 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. 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. 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).

-- 
Raoul Gough.
export LESS='-X'