On Wed, Dec 7, 2011 at 9:47 PM, Neil Groves <neil@grovescomputing.com> wrote:
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've requested an iterator_size trait: https://svn.boost.org/trac/boost/ticket/6240 Maybe that could be used once implemented.
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.
Something like contiguous_range or ptr_range? It'd also be nice if you could easily construct a ptr range from array, string and vector. Any rough ETA? -- Olaf