From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-09-09 11:50:23
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
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 >
typedef unsigned short type;
typedef unsigned int type;
typedef unsigned long type;
struct add_unsigned<long long>
typedef unsigned long long type;
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
> is also well formed and has the same meaning:
> using namespace unspecified-namespace;
> 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
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. (I have found no good way 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
We might want to say the following:
T models a Range if it models one of the following concepts
where a MemberwiseRange concept has the following requirements
T::size() const; // optional
and where a FreestandingRange concept has the following requirements
boost_range_begin( t );
boost_range_begin( ct );
boost_range_end( t );
boost_range_end( ct );
boost_range_size( t );
boost::begin() is then defined as
- call boost_range_begin(t) if it exist in users namespace
- otherwise call t.begin()
[similarly for other functions]
Hm...I dunno...does it make sense?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk