[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]
>>>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>>>> On the other hand, perhaps this does belong purely in the
>>>>> ContainerTraits concept. I wonder whether assignability is always a
>>>>> quality of a container (and all instances of it) or just the
>>>>> particular type of value stored in a particular instance. In the case
>>>>> of the STL containers, I think all template arguments are required to
>>>>> be Assignable types
>>>>
>>>> Yes, but...
>>>>
>>>>> and some of the containers (set and map) add
>>>>> const qualification somewhere in their value_type.
>>>>
>>>> ...that fact tends to make the value_type not Assignable.
>>>
>>> Of course. I was just thinking about whether it's conceptually related
>>> to the template arguments or rather to some property of the container
>>> template. I guess it doesn't actually make much practical difference
>>> in terms of providing the necessary partial specializations.
>>> Of course. I was just thinking about whether it's conceptually related
>>> to the template arguments or rather to some property of the container
>>> template. I guess it doesn't actually make much practical difference
>>> in terms of providing the necessary partial specializations.
>
> I've figured out what was bugging me about this. For example,
> supporting std::map this way would require a partial specialization
> for std::pair<X const, Y>. More generally, there has to be a
> value_traits (or is_assignable) specialization for the container's
> value_type, which could be something non-obvious to the client code
> (e.g. container arguments X and Y, but must specialize on
> weird_thing<X, more_weirdness<Y> >).  

Well, you could specialize

  template <class T, class U>
  struct is_assignable<std::pair<T,U> >
    : mpl::and_<is_assignable<T>, is_assignable<U> >
  {};
    
But in general I understand what you're saying.

> In the worst case, a container could use a nested class, for which
> you can't provide a partial specialization at all (non-deduced
> context and all that).

Yep, good point.

>>> David Abrahams <dave at boost-consulting.com> writes:
> [snip]
>>>> No, an iterator's value_type is never const.
>>>
>>> Hmmmmm... That's really a bit of a shame, since I go to so much
>>> trouble to pass const_iterator or iterator to the iterator_traits base
>>> class, depending on whether the container has top-level const
>>> qualification or not :-) 
>>
>> What does this have to do with the _container's_ const qualification?
>>
>> 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.

>>> I say "would be" because neither of them is at all convenient to do
>>> on MSVC6 owing to the lack of PTS.
>>
>> How does that come into play?  It's my policy not to make major
>> interface compromises for broken compilers.
>
> Good point. It's not that difficult I suppose, just providing an
> override for the container_traits ValueTraits parameter in the
> workaround templates like set_suite and map_suite. Otherwise it would
> all use value_traits<typename Container::value_type> and (without PTS)
> get the wrong answers.
>
> 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.

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

> The only downside is the syntactic mess this will probably create:
>
>   BOOST_STATIC_CONSTANT (int, feature_flags =
>       (base_class::feature_flags &
>        ~(is_const<mumble> ? reorderable_flag : 0)) |
>       (something_else ? another_flag : 0));
>
> Then again, maybe it doesn't have to be soooo bad:
>
> private:
>   BOOST_STATIC_CONSTANT (int, cancelled =
>       is_const<mumble> ? reorderable_flag : 0;
>
>   BOOST_STATIC_CONSTANT (int, added =
>       something_else ? another_flag : 0);
>
> public:
>   BOOST_STATIC_CONSTANT (int, feature_flags =
>       (base_class::feature_flags & ~cancelled) | added);
>
> Any thoughts?

See above.

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