Re: [boost] difference_type size()?

Subject: Re: [boost] difference_type size()?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-10-19 15:27:31

On Wed, Oct 19, 2011 at 12:09 PM, <andrey.semashev_at_[hidden]> wrote:

> On Wednesday, October 19, 2011 11:50:06 Jeffrey Lee Hellrung, Jr. wrote:
> > > Making the size signed makes little sense to me and it also
> > > introduces a problem (rather theoretical, however) when iterator_range
> > > is constructed from
> > > a very large valid range, whose size exceeds
> > > numeric_limits<difference_type>::max().
> >
> > How would that be possible?  Doesn't that violate the conditions on
> > difference_type that it is able to represent the (signed) distance
> between
> > any two iterators within the same range?
>
> That is only true for random access iterators. See std::distance reference
> (24.4.4/4):
>
> Effects: If InputIterator meets the requirements of random access iterator,
> returns (last - first); otherwise, returns the number of increments needed
> to
> get from first to last.
>
> So bidirectional iterators, for instance, may denote a valid range that
> exceeds difference_type capacity. This is actually a little caveat in the
> Standard.
>

A bit surprising, but I'll take your word for it.  In any case, it's some
irrelevant for non-random-access iterators as iterator_range::size() is only
defined for random access iterators, no?

> > Also, assuming that size() should return an unsigned integer type (I'm
> not
> > debating the merits of this), *what* unsigned integer type should that
> be?
> > I don't know of any general way to go from difference_type to a
> "compatible"
> > unsigned integer type.  I suspect this will end up being filed away as
> > "nice to have but ultimately unimplementable generically" given current
> > range interfaces.
>
> I think the following would do:
>
>  typedef typename make_unsigned< difference_type >::type size_type;
>

I was under the impression that most of the traits in Boost.TypeTraits of
this nature are only defined for builtin types.

- Jeff