Re: [boost] size() type

Subject: Re: [boost] size() type
From: Neil Groves (neil_at_[hidden])
Date: 2011-12-07 15:47:22

On Tue, Dec 6, 2011 at 11:26 AM, Olaf van der Spek <ml_at_[hidden]> wrote:

> On Thu, Dec 1, 2011 at 6:45 PM, Thorsten Ottosen
> <thorsten.ottosen_at_[hidden]> 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