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.
> > 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk