-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Flinn Sent: Thursday, February 21, 2013 4:06 PM To: boost@lists.boost.org 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@gmail.com> wrote:
On Wed, Feb 20, 2013 at 12:55 PM, Neil Groves <neil@grovescomputing.com
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 +44 1539 561830 07714330204 pbristow@hetp.u-net.com