Re: [boost] size() type

Subject: Re: [boost] size() type
From: Olaf van der Spek (ml_at_[hidden])
Date: 2011-12-08 05:52:23

On Wed, Dec 7, 2011 at 9:47 PM, Neil Groves <neil_at_[hidden]> 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