[range] range_size metafunction deprecated?
Hi, I noticed Range Library Core proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2068.html) removed 'range_size' metafunction. It was replaced by 'range_difference'? (But, cvs head is not affected.) If so, why 'std::size' too is proposed? 'std::distance' seems enough. -- Shunsuke Sogame
shunsuke wrote:
Hi,
I noticed Range Library Core proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2068.html) removed 'range_size' metafunction. It was replaced by 'range_difference'? (But, cvs head is not affected.)
Right. A proposal for the standard and boost is two different things.
If so, why 'std::size' too is proposed? 'std::distance' seems enough.
So that you may have the guarantee that the function is O(1) complexity. -Thorsten
Thorsten Ottosen wrote:
shunsuke wrote:
Hi,
I noticed Range Library Core proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2068.html) removed 'range_size' metafunction. It was replaced by 'range_difference'? (But, cvs head is not affected.)
Right. A proposal for the standard and boost is two different things.
The 'boost::range_size' of 'iterator_range' is defined as 'std::size_t'. Can it guarantee to represent any difference_type of iterator?
If so, why 'std::size' too is proposed? 'std::distance' seems enough.
So that you may have the guarantee that the function is O(1) complexity.
'std::distance'(24.3.4/1) also seems to guarantee it? -- Shunsuke Sogame
shunsuke wrote:
Thorsten Ottosen wrote:
shunsuke wrote:
Hi,
I noticed Range Library Core proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2068.html) removed 'range_size' metafunction. It was replaced by 'range_difference'? (But, cvs head is not affected.)
Right. A proposal for the standard and boost is two different things.
The 'boost::range_size' of 'iterator_range' is defined as 'std::size_t'. Can it guarantee to represent any difference_type of iterator?
Probably not. Anyway, I plan to change boost::size() to return iterator_difference. (If there is one thing I hate about C++ containers it has to be the use of unsigned.)
If so, why 'std::size' too is proposed? 'std::distance' seems enough.
So that you may have the guarantee that the function is O(1) complexity.
'std::distance'(24.3.4/1) also seems to guarantee it?
Only for random access iterators. std::size() would only accept random access iterators. -Thorsten
Thorsten Ottosen wrote:
shunsuke wrote:
Thorsten Ottosen wrote:
shunsuke wrote:
Hi,
I noticed Range Library Core proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2068.html) removed 'range_size' metafunction. It was replaced by 'range_difference'? (But, cvs head is not affected.) Right. A proposal for the standard and boost is two different things.
The 'boost::range_size' of 'iterator_range' is defined as 'std::size_t'. Can it guarantee to represent any difference_type of iterator?
Probably not.
Anyway, I plan to change boost::size() to return iterator_difference.
(If there is one thing I hate about C++ containers it has to be the use of unsigned.)
If so, why 'std::size' too is proposed? 'std::distance' seems enough. So that you may have the guarantee that the function is O(1) complexity.
'std::distance'(24.3.4/1) also seems to guarantee it?
Only for random access iterators. std::size() would only accept random access iterators.
Hmm, when should I use 'std::size'? Whenever the argument is known to be RandomAccessRange, the 'std::distance' is known to be O(1) complexity. Thus, I will always use 'std::distance'. (I actually replaced all the 'boost::size' in my codes by 'boost::distance'.) Any pitfalls? -- Shunsuke Sogame
shunsuke wrote:
Thorsten Ottosen wrote:
Only for random access iterators. std::size() would only accept random access iterators.
Hmm, when should I use 'std::size'? Whenever the argument is known to be RandomAccessRange, the 'std::distance' is known to be O(1) complexity. Thus, I will always use 'std::distance'. (I actually replaced all the 'boost::size' in my codes by 'boost::distance'.)
Right, but size() adds a compile time check to that. Of course, you may get that with a concept check in the beginning too. -Thorsten
Thorsten Ottosen wrote:
shunsuke wrote:
Thorsten Ottosen wrote:
Only for random access iterators. std::size() would only accept random access iterators.
Hmm, when should I use 'std::size'? Whenever the argument is known to be RandomAccessRange, the 'std::distance' is known to be O(1) complexity. Thus, I will always use 'std::distance'. (I actually replaced all the 'boost::size' in my codes by 'boost::distance'.)
Right, but size() adds a compile time check to that. Of course, you may get that with a concept check in the beginning too.
I got it. I should agree different functions should have different names before wrapped around. Regards, -- Shunsuke Sogame
participants (2)
-
shunsuke -
Thorsten Ottosen