On Tue, Feb 19, 2013 at 5:00 PM, Thorsten Ottosen < thorsten.ottosen@dezide.com> 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>