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