Re: [boost] [range] How to extend Boost.Range?

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

- 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. (I have found no good way to
formulate this.)

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

- MemberwiseRange
- FreestandingRange

where a MemberwiseRange concept has the following requirements

T::begin();
T::begin() const;
T::end();
T::end() const;
T::size() const; // optional 
T::iterator;
T::const_iterator;

and where a FreestandingRange concept has the following requirements

boost::range_iterator<T>::type
boost::range_const_iterator<T>::type
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?

br

Thorsten