Subject: [boost] [offlist] Re: [range] [general] making member functions SFINAE-friendly
From: Neil Groves (neil_at_[hidden])
Date: 2013-02-19 11:46:15
Hello! I agree that the current implementation of size() sucks. I think the
standard library design is a bit pants too. I intend to make providing
implementations of size via ADL extension points. Once this has been done
I'll make the boost::size algorithm work via this extension point and
deprecate the iterator_range::size() member function.
I inherited this mistake IIRC.
I'm happy to sort it out. Just give me some time. I'm busy crushing Getco
On Mon, Feb 18, 2013 at 10:50 AM, Jonathan Wakely
> 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.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk