Re: boost range for non integers

From: Wim Leflere (wim.leflere_at_[hidden])
Date: 2020-01-10 16:10:10

If the float range uses a float iterator that is based on
'integer_iterator_with_step', the 'progress' of the iterator would be
stored as an integer value, the step member variable.
So iterator increment and equality are safe from floating point issues as
the integer step value would be used.
https://github.com/boostorg/range/blob/develop/include/boost/range/irange.hpp#L111

I was thinking of the Date type from <chrono>, not the one from Boost.

Wim Leflere

On Fri, Jan 10, 2020 at 1:05 PM Neil Groves <neilgroves_at_[hidden]> wrote:

>
>
> On Thu, 9 Jan 2020 at 21:45, Wim Leflere via Boost <boost_at_[hidden]>
> wrote:
>
>> Hello,
>>
>> I was wondering why the (i)range function is limited to integers.
>>
>> https://www.boost.org/doc/libs/1_72_0/libs/range/doc/html/range/reference/ranges/irange.html
>>
>>
>> It would be nice if it also supported floats.
>> Or any 'incrementable' class, e.g. Date.
>>
>>
> Support for floating point was consciously not included since it would be
> highly likely to cause problems. The inequality of a float range would
> almost certainly require a predicate to consider the appropriate epsilon.
> We could have coped with the precondition constraints for rejecting NaN but
> the inequality predicate problem means a different interface. I therefore
> concluded it was not a priority. I am of the current opinion that it is of
> very little value, and potentially negative utility to provide this in
> Boost.Range.
>
> For Date since Boost.DateTime provides the TimeIterator one can create a
> range. There is a general idioms for creating ranges from iterators see
> make_iterator_range, iterator_range, sub_range etc. Hence the specific name
> is not provided since it is not required.
>
> The reason I did not generally support making a range from an
> Incrementable is because Incrementable is necessary but not sufficient.
>
>
>
>> Regards,
>> Wim Leflere
>>
>>
> HTH,
> Neil Groves
>