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

Subject: Re: [boost] [range] [general] making member functions SFINAE-friendly
From: Neil Groves (neil_at_[hidden])
Date: 2013-02-19 18:11:08

On Tue, Feb 19, 2013 at 5:00 PM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> On 18-02-2013 13:32, Mathias Gaunard wrote:
>
>> On 18/02/13 06:30, Nathan Ridge wrote:
>>
>>  The suggested workaround is to give iterator_range a base class,
>>> specialize this base class for random-access iterators, and only
>>> define size() in this specialization.
>>>
>>
>> This kind of thing is very tedious to do, this is exactly why
>> class-scope static_if is so useful.
>>
>
> Would using enable_if on size() not solve the problem?
>
>
I think this is tricky to achieve without obfuscating the code, which might
be ok. I've been dissatisfied when attempting to optimally write generic
algorithms and require size. Obviously I've found this to be a more general
problem than with just iterator_range. It is a problem that plagues the
development of writing generic algorithms. Frequently knowing if one has
access to an O(1) size appreciably changes an optimal implementation. Dave
mentioned that std::map has O(1) size and yet from the iterators we only
have access to non-member distance.

I have been wrestling with this issue for some time, and think that
deprecating the member function size() on iterator_range combined with the
provision of an extensible boost::size(rng) that has O(1) would be a
reasonable compromise. We have boost::distance already which provides the
complexity guarantee equivalent of std::distance. If we add
boost::size(rng) that delegates to range_size then I could provide
implemetentations for the standard containers, and users could augment the
behaviour to keep O(1) size for other containers, and could even choose to
loosen the performance guarantee if they desired.

To me this seems simpler than having more base classes, but comes at the
cost of eventually breaking backward compatibility.

I've been very wary to discuss this since I've never managed to convince
myself sufficiently that this is the optimal solution. I'm extremely
reluctant to break interfaces, but with a sufficient period for the
deprecation perhaps the community would prefer this option?

I'm very keen to hear the thoughts of current users since I am unsure how
much code relies upon iterator_range member size() function. Additionally I
bet Thorston and Nate have some great ideas.

-Thorsten
>
>
>
Thanks for all of your help and input, and sorry for being so slow to
address some of these issues.

Regards,
Neil Groves

>
> ______________________________**_________________
> Unsubscribe & other changes: http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>