[C++-sig] Re: indexing_v2 status update
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:
>>>> template<typename Container, typename ValueTraits = detail::no_override>
>>>> struct base_container_traits
>>>> : public ::boost::python::indexing::iterator_traits<
>>>> BOOST_DEDUCED_TYPENAME mpl::if_<
>>>> BOOST_DEDUCED_TYPENAME Container::const_iterator,
>>>> BOOST_DEDUCED_TYPENAME Container::iterator
>>>> 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
>> 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
always gives the "right" answer for has_mutable_ref and therefore
is_reorderable as well.
>>> 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
More information about the Cplusplus-sig