On Tue, Dec 6, 2011 at 11:26 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Dec 1, 2011 at 6:45 PM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Den 01-12-2011 14:02, Olaf van der Spek skrev:
Hi,
Any progress on these tickets? Would be nice to have a solution.
size() return type should be size_type, not difference_type: https://svn.boost.org/trac/boost/ticket/5971
data() for iterator_range: https://svn.boost.org/trac/boost/ticket/5930
If Neil agrees on them and their resolution, I can implement them.
Neil?
Please accept my apologies for the delay in responding. I've been in read-only mode for a while about these. I think that having the result be unsigned does make sense and the most compelling argument, for me, is that a standard container is also a model of a one of the Range Concepts. I'm completely happy for Thorsten to make this change. I would be able to do it in the next couple of weeks once I have dug myself out of the mountain of work I have managed to accumulate! Thorsten will probably be able to make these changes sooner than I, I suspect. I am not happy with the inclusion of data() being a member function that conditionally becomes a part of the iterator_range interface in a subset of conditions that we detect as being contiguous. I don't feel this improves the approximation with standard containers in the same manner that returning an unsigned type from size does. The standard containers either do or don't provide data() regardless of the template arguments use in the instantiation. Looking more formally at the problem I regard any property of the underlying types that adds or subtracts functions as something that should be modelled as a proper Concept. I have an implementation that formalizes contiguous ranges and higher-dimensional ranges that I have been acquiring real-world experience with. My intent is to put this into Boost.Range once I am happy with the interface and the Concepts.
-- Olaf
Thanks for bringing this topic up. Regards, Neil Groves