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

Subject: Re: [boost] [range] [general] making member functions SFINAE-friendly
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-02-21 11:49:17

On Thu, Feb 21, 2013 at 2:18 AM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> 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.
>

Agreed.

As I understand it, there is a wish from som 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

Either way, customizing a trait/providing an overload for every standard
> and boost container seems to be a solution that scales poorly
> and which requires huge amounts of code to be included.
>

This can be mitigated somewhat if range_calculate_size(r) defaults to
r.size() if that is available, but there's the tradeoff that r publishes a
non-O(1) size member function, in which case range_calculate_size must be
explicitly overridden. And then there are the cases when r.size() static
asserts :/

In any case, providing an overload for every standard and boost container
is what we already do with swap, so there is precedent.

- Jeff