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