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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-09-02 11:15:51

Eric Niebler <eric <at> boost-consulting.com> writes:

> 
> Thorsten Ottosen wrote:
> > Eric Niebler <eric <at> boost-consulting.com> writes:
> >>
> >>Please enlighten me as to the proper way 
> >>to extend your library.
> > 
> 
> <snip>
> 
> > way 2: (lacking from docs)
> > 
> > (a) provide free-standing member in namespace of the UDT:
> >    - begin()
> >    - end()
> >    - size()
> > 
> > (b) provide specializations for 
> > 
> >   - boost::range_itetator
> >   - boost::range_const_iterator
> >   - boost::range_value
> >   - boost::range_difference
> >   - boost::range_size
> > 
> > A library might choose not to call boost::begin/end/size
> > unqualified...in which case that library does not support
> > UDTs.
> > 
> > Does it make sense? Have I forgotten something?
> 
> It does *not* make sense, 

Ok. What part does not make sense?

>and I think you forgot the long discussion we 
> had on this topic with Dave A. and Peter D. on the boost.users list. 
> (Thread starts here: http://lists.boost.org/boost-users/2005/03/10242.php)
> 
> See http://lists.boost.org/boost-users/2005/03/10391.php where you wrote:
> 
> "So this changes the extension protocol to overloading adl_end() from 
> overloading end()."

I recall some of the discussion, but I haven't read up on it.
The adl_end() stuff never got further than the discussion. 

> You also seem to be forgetting the Range concepts that you yourself 
> documented here: http://boost.org/libs/range/doc/range.html. In the 
> concepts, the calls to begin()/end() are REQUIRED to be qualified.

well, the boost:: qualification was added for 1.33 because Dave wanted that to
happen. I belive the problem was that without boost:: qualification, standard
containers were not conforming to a range concept. Somebody suggested the
requirement

using boost:begin;
begin(r);

instead. Dave rejected it.

If that is wrong afterall, then the whole area of specifying concepts for free-
standing functions is a mess.
 
> So I'll ask again, what is the proper way to extend your library?

Do you agree that the above change would help?

> While we're on the topic, what is the point of range_value, 
> range_difference and range_size? Will range_value<Range>::type ever be 
> different than 
> std::iterator_traits<range_iterator<Range>::type>::value_type? If the 
> answer is no, then why do we need range_value?

as a help, a shorter way of writing it. 

br

Thorsten