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

David Abrahams dave at boost-consulting.com
Thu Dec 4 03:53:36 CET 2003


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

> David Abrahams <dave at boost-consulting.com> writes:
>
> [snip]
>> I don't understand is_reorderable.  How is that different from
>>
>>   is_convertible<
>>       iterator_traits<C::iterator>::iterator_category
>>     , forward_iterator_tag
>>   >::value
>>   && is_non_const_lvalue_iterator<C::iterator>::value
>>   && is_assignable<C::value_type>::value
>>
>> ??
>>
>> I realize we don't have is_assignable, but shouldn't you phrase this
>> in terms of something fundamental like value_type assignability?  We
>> can ask all the other questions (see
>> boost/iterator/is_lvalue_iterator.hpp).
>
> It looks like assignability is the really important test for
> determining whether a container can be reordered (i.e. sorted or
> reversed). However, I can't think of any way to implement an
> is_assignable template. 

Neither can anyone else, other than specializing for known types and
asking the user to specialize for his own.

> For instance, std::pair<const int, int> is not
> assignable, yet it doesn't have top-level const qualification, and it
> *does* have an operator= (which will produce a compile-time error if
> used) so I don't think any has_member_function test will help. 

Right.  But you can provide partial specializations for
std::pair<const T, const U>, 
std::pair<T, const U>, 
std::pair<const T, U>.

> If anyone can suggest a workable is_assignable, I'll use it to
> deduce is_reorderable, but otherwise I think I'll just stick with
> is_mutable_ref and explicit overrides for some containers
> (i.e. std::map)

I *think* I still think that's an inferior solution.

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





More information about the Cplusplus-sig mailing list