Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-09-09 11:26:45

Eric Niebler <eric <at>> 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;

                struct add_unsigned<short>
                        typedef unsigned short type;
                struct add_unsigned<int>
                        typedef unsigned int type;

                struct add_unsigned<long>
                        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;
> boost_range_begin(x);
> 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


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

We might want to say the following:

T models a Range if it models one of the following concepts

Boost list run by bdawes at, gregod at, cpdaniel at, john at