On 18 February 2013 10:19, Nathan Ridge wrote:
Could you share a use case that requires to depend on size() specifically rather than the iterator category?
Given an arbitrary range r, determine its size by the fasest means possible.
If we use std::distance, we can do it in O(1) for std::vector, O(n) for std::map, and O(n) for std::forward_list.
If we can detect whether "r.size()" is a valid expression, and use that if available, and std::distance otherwise, then we have O(1) for std::vector, O(1) for std::map, and O(n) for std::forward_list. Notice how that's an improvement for std::map.
However, if detecting whether "r.size()" is a valid expression cannot be done reliably (for example, if we determine that for iterator_range<I> where I is not random-access it is a valid expression, but then that static-asserts on us), then we can't use this approach.
Yes, that perfectly sums up my use case, thanks. I'm not "Depending on members of a third party component", I'm writing a generic component and someone tried to use it with boost::iterator_range and asked me why it didn't work. The reason iterator_range::size() doesn't use std::distance is given at http://permalink.gmane.org/gmane.comp.lib.boost.devel/193055 I think it's a valid choice to only allow size() when its O(1), c.f. std::forward_list, but I think it would be even better to not even define it when it can't be used, c.f. std::forward_list.