Re: [boost] [range] [general] making member functions SFINAE-friendly

Subject: Re: [boost] [range] [general] making member functions SFINAE-friendly
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2013-02-21 11:29:04

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Jeff Flinn
> Sent: Thursday, February 21, 2013 4:06 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [range] [general] making member functions SFINAE-friendly
> 
> On 2/21/2013 5:18 AM, Thorsten Ottosen wrote:
> > On 20-02-2013 22:12, Neil Groves wrote:
> >> On Wed, Feb 20, 2013 at 9:02 PM, Jeffrey Lee Hellrung, Jr. <
> >> jeffrey.hellrung_at_[hidden]> wrote:
> >>
> >>> On Wed, Feb 20, 2013 at 12:55 PM, Neil Groves
> >>> <neil_at_[hidden]
> >>>> wrote:
> >>> [...]
> >>>
> >>>> I agree. My suggestion didn't have a new base class. I think by
> >>>> making
> >>>> boost::size(rng) call range_size(rng) we can provide an extension
> >>>> method similar to that already provided for boost::begin(rng) and
> >>> boost::end(rng).
> >>>>
> >>>
> >>> You mean like range_calculate_size [1] ?
> >>>
> >>> Exactly I thought that when I introduced this it has been quite
> >> successful, and that we could build upon this by adding the optimal
> >> implementations for standard library components. I have been using
> >> this as an extension mechanism privately in this manner for a while
> >> and it has worked well for me. I wanted to get other peoples views on
> >> this solution before making the extension mechanism more widely used
> >> and optimised by default for the standard library containers.
> >
> > I would like to keep boost::size() O(1). Anybody that writes code
> > relying on boost::size() should know that this is guaranteed.
> >
> > As I understand it, there is a wish from some users to get a size even
> > when O(1) time is not possible. This suggest to me that we also need
> > to extend boost::distance() to work for containers.

+1  (though I don't like the name much - is length possible name?)

Paul

PS I think that the Standard is unwise in specifying what seems to me a Quality of Implementation
issue.
It should specify that the implementation should document what is achieves (or even probably
achieves - I'm not sure that is it always fixed).

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]