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 <
> 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]
>>> 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
>>> You mean like range_calculate_size  ?
>>> 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 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.
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
In any case, providing an overload for every standard and boost container
is what we already do with swap, so there is precedent.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk