Eric Niebler <eric <at> boost-consulting.com> writes:
This looks good. Thanks for taking care of this. I still have a problem with range_value<> and friends. To satisfy the Range concept, users are required to specialize boost::range_value<> in spite of the fact that it will always be equivalent to std::iterator_traits<Range>::value_type. This makes Range harder to extend for no benefit. The Range library can provide range_value<> without requiring users to specialize it.
right. I have comitted a revision that deduces - range_size - range_difference - range_value based on the iterator types. I don't know how much code this will break, but I hope it won't break much. We'll see when the next regression pop up tomorrow. Btw, my range_size uses this code template< class T > struct add_unsigned; template<> struct add_unsigned<short> { typedef unsigned short type; }; template<> struct add_unsigned<int> { typedef unsigned int type; }; template<> struct add_unsigned<long> { typedef unsigned long type; }; #ifdef BOOST_HAS_LONG_LONG template<> struct add_unsigned<long long> { typedef unsigned long long type; }; #endif Can anybody spot weaknesses in that approach?
Regarding the concepts, it is correct to say, as you do, that the calls to begin(), end(), et al., must be qualified by boost::. But they also must say that the following
<quote>
is also well formed and has the same meaning:
using namespace unspecified-namespace; boost_range_begin(x); </quote>
I think you should also say somewhere (but not necessarily in the Concepts section) that unspecified-namespace contains the implementations of boost_range_begin(), et al., for the std containers, std::pair, arrays and null-terminated strings. I think that should do it. Does anybody have a better suggestion?
The Range concepts have been a fruitful source of confusion. I'm still myself a bit puzzled sometimes :-) We want to say a range r supports the expressions boost::begin(r) boost::end(r) boost::size(r) That is true fo certain types if we do include a certain header, otherwise it is not. That has really irritated me: in one translation-unit T could be conforming to a range, in others it need not to. If we use your quote above, it seems to me that the to expressions are not equivalent: you can't exchange one with the other. A Range concept is composed of more than the concept defining boost_range_begin()/boost_range_end(). We might want to say the following: T models a Range if it models one of the following concepts