[range] range_size<T> deprecation, updated docs etc.
Dear all, As suggested by several people, I have started to rely on range_difference<T>::type in all places of the library. I have also updated the docs w.r.t new concepts and are working on polishing them. 1.35 will introduce a new function template< class T > BOOST_DEDUCED_TYPENAME range_difference<T>::type size( const T& r ); that requires T to be a random access range. I also want to put a post-condition saying "result >= 0", but was a bit in doubt when I read the standards wording for std::distance(): "template<class InputIterator> typename iterator_traits<InputIterator>::difference_type distance(InputIterator first, InputIterator last); 4 Effects: Returns the number of increments or decrements needed to get from first to last. 5 Requires: last shall be reachable from first." How can one ever use decrements to get from first to last? Any comments? -Thorsten
on Fri Nov 09 2007, Thorsten Ottosen <nesotto-AT-cs.aau.dk> wrote:
Dear all,
As suggested by several people, I have started to rely on range_difference<T>::type in all places of the library.
I have also updated the docs w.r.t new concepts and are working on polishing them.
1.35 will introduce a new function
template< class T > BOOST_DEDUCED_TYPENAME range_difference<T>::type size( const T& r );
Really, you're returning the difference_type and not the size_type?
that requires T to be a random access range. I also want to put a post-condition saying "result >= 0", but was a bit in doubt when I read the standards wording for std::distance():
"template<class InputIterator> typename iterator_traits<InputIterator>::difference_type distance(InputIterator first, InputIterator last); 4 Effects: Returns the number of increments or decrements needed to get from first to last. 5 Requires: last shall be reachable from first."
How can one ever use decrements to get from first to last?
When InputIterator is a random access iterator, last < first does not violate the precondition. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams skrev:
on Fri Nov 09 2007, Thorsten Ottosen <nesotto-AT-cs.aau.dk> wrote:
Dear all,
As suggested by several people, I have started to rely on range_difference<T>::type in all places of the library.
I have also updated the docs w.r.t new concepts and are working on polishing them.
1.35 will introduce a new function
template< class T > BOOST_DEDUCED_TYPENAME range_difference<T>::type size( const T& r );
Really, you're returning the difference_type and not the size_type?
Yes, that was the intension. Iterators don't have a size_type per se, and so it complicated the whole thing a little to make the user worry about this. -Thorsten
Thorsten Ottosen wrote:
David Abrahams skrev:
on Fri Nov 09 2007, Thorsten Ottosen <nesotto-AT-cs.aau.dk> wrote:
Dear all,
As suggested by several people, I have started to rely on range_difference<T>::type in all places of the library.
I have also updated the docs w.r.t new concepts and are working on polishing them.
1.35 will introduce a new function
template< class T > BOOST_DEDUCED_TYPENAME range_difference<T>::type size( const T& r );
Really, you're returning the difference_type and not the size_type?
Yes, that was the intension. Iterators don't have a size_type per se, and so it complicated the whole thing a little to make the user worry about this.
-Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Would it be better to use a meta-function 'make_unsigned' which converts signed type to its correspondent unsigned type? For example: signed int => unsigned int ::std::ptrdif_t => ::std::size_t etc. I've used it for my iterator range: http://tools.assembla.com/cbear/browser/trunk/cbear.berlios.de/range.
Sergey Shandar skrev:
Thorsten Ottosen wrote:
David Abrahams skrev:
on Fri Nov 09 2007, Thorsten Ottosen <nesotto-AT-cs.aau.dk> wrote:
Dear all,
As suggested by several people, I have started to rely on range_difference<T>::type in all places of the library.
I have also updated the docs w.r.t new concepts and are working on polishing them.
1.35 will introduce a new function
template< class T > BOOST_DEDUCED_TYPENAME range_difference<T>::type size( const T& r );
Really, you're returning the difference_type and not the size_type?
Yes, that was the intension. Iterators don't have a size_type per se, and so it complicated the whole thing a little to make the user worry about this.
-Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Would it be better to use a meta-function 'make_unsigned' which converts signed type to its correspondent unsigned type? For example:
signed int => unsigned int ::std::ptrdif_t => ::std::size_t etc.
I don't really know if it's better. -Thorsten
Thorsten Ottosen wrote:
Really, you're returning the difference_type and not the size_type?
Yes, that was the intension. Iterators don't have a size_type per se, and so it complicated the whole thing a little to make the user worry about this.
I think that "size" was an inappropriate name. I don't know why "distance_of_random_access" was named "size". Iterators don't have a "size" per se. :-) Regards, -- Shunsuke Sogame
shunsuke skrev:
Thorsten Ottosen wrote:
Really, you're returning the difference_type and not the size_type? Yes, that was the intension. Iterators don't have a size_type per se, and so it complicated the whole thing a little to make the user worry about this.
I think that "size" was an inappropriate name. I don't know why "distance_of_random_access" was named "size". Iterators don't have a "size" per se. :-)
no, but an half-open iterator range [x,y) has a size. -Thorsten
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Viernes, Noviembre 9, 2007 4:23 pm Asunto: Re: [boost] [range] range_size<T> deprecation, updated docs etc. Para: boost@lists.boost.org
on Fri Nov 09 2007, Thorsten Ottosen <nesotto-AT-cs.aau.dk> wrote:
[...]
"template<class InputIterator> typename iterator_traits<InputIterator>::difference_type distance(InputIterator first, InputIterator last); 4 Effects: Returns the number of increments or decrements needed to get from first to last. 5 Requires: last shall be reachable from first."
How can one ever use decrements to get from first to last?
When InputIterator is a random access iterator, last < first does not violate the precondition.
I'm afraid (last<first) violates the precondition even with random access iterators, according to 24.1.6 and as explicitly acknowledged at http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204 . This is IMHO an unfortunate decision by the committee and renders the "or decrements" bit in the effects clause of std::distance void and misleading. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN LOPEZ MU?Z skrev:
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Viernes, Noviembre 9, 2007 4:23 pm Asunto: Re: [boost] [range] range_size<T> deprecation, updated docs etc. Para: boost@lists.boost.org
on Fri Nov 09 2007, Thorsten Ottosen <nesotto-AT-cs.aau.dk> wrote: [...]
"template<class InputIterator> typename iterator_traits<InputIterator>::difference_type distance(InputIterator first, InputIterator last); 4 Effects: Returns the number of increments or decrements needed to get from first to last. 5 Requires: last shall be reachable from first."
How can one ever use decrements to get from first to last? When InputIterator is a random access iterator, last < first does not violate the precondition.
I'm afraid (last<first) violates the precondition even with random access iterators, according to 24.1.6 and as explicitly acknowledged at http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204 . This is IMHO an unfortunate decision by the committee and renders the "or decrements" bit in the effects clause of std::distance void and misleading.
Thanks for the link. I'm convinced that boost::size(Rng&) can assert the result to be positive and similar for boost::distance(Rng&). The Range concept requires "forward" reachability; otherwise [x,y) makes no sense. -Thorsten
on Fri Nov 09 2007, "JOAQUIN LOPEZ MU?Z" <joaquin-AT-tid.es> wrote:
De: David Abrahams <dave@boost-consulting.com>
on Fri Nov 09 2007, Thorsten Ottosen <nesotto-AT-cs.aau.dk> wrote: [...]
"template<class InputIterator> typename iterator_traits<InputIterator>::difference_type distance(InputIterator first, InputIterator last); 4 Effects: Returns the number of increments or decrements needed to get from first to last. 5 Requires: last shall be reachable from first."
How can one ever use decrements to get from first to last?
When InputIterator is a random access iterator, last < first does not violate the precondition.
I'm afraid (last<first) violates the precondition even with random access iterators, according to 24.1.6 and as explicitly acknowledged at http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204 .
I don't see how to read the issue resolution so it says that.
This is IMHO an unfortunate decision by the committee and renders the "or decrements" bit in the effects clause of std::distance void and misleading.
I do agree that the decision is unfortunate. The wording is clearly misleading. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams ha escrito:
on Fri Nov 09 2007, "JOAQUIN LOPEZ MU?Z" <joaquin-AT-tid.es> wrote:
I'm afraid (last<first) violates the precondition even with random access iterators, according to 24.1.6 and as explicitly acknowledged at http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204 .
I don't see how to read the issue resolution so it says that.
The resolution states that the definition of "reachable" to be taken into account is the one given in 24.1/6, which depends only on operator ++. "An iterator j is called reachable from an iterator i if and only if there is a finite sequence of applications of the expression ++i that makes i == j" Hence if last<first, last is *not* reachable from first; there is no finite sequence of applications of operator++() to first that gives you last. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (7)
-
"JOAQUIN LOPEZ MU?Z" -
David Abrahams -
Joaquín Mª López Muñoz
-
Sergey Shandar -
shunsuke -
Thorsten Ottosen -
Thorsten Ottosen