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

Raoul Gough RaoulGough at yahoo.co.uk
Wed Dec 10 10:19:33 CET 2003


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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> David Abrahams <dave at boost-consulting.com> writes:
>>
>>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>>
[snip]
>>>>   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".

::boost::python::indexing::iterator_traits. It provides some typedefs,
has_copyable_iter, is_reorderable and index_style, although
is_reorderable isn't reliable, for the reasons we are currently
discussing.

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

That's right. Initially I thought that checking whether
remove_reference<typename iter::reference> was const qualified would
do the trick (well, except for std::map) but it doesn't seem to work
on some libraries for std::set either. 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.

>
>> [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? ;-)

True. Does mpl::set currently work? I seem to remember that you
suggested using mpl::vector at the moment, which raised some doubt
about this.

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





More information about the Cplusplus-sig mailing list