On 20-02-2013 00:11, Neil Groves wrote:
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 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.
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.
-1 for the idea of introducing another base class. Breaking the interface could be done, but I guess we would have 2 or three releases before it actually came into the code? What's the official Boost policy on this matter? I don't know how much that time line would help Jonathan's clients or those writing generic code that accepts an O(n) time size operation. Having a tool for getting the O(1) size() from containers which currently fail to work with boost::size() would be good. However, how do we do that without concept-based overloading? -Thorsten