boost range for non integers

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

boost range for non integers

Boost - Dev mailing list
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.

Regards,
Wim Leflere

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: boost range for non integers

Boost - Dev mailing list
On Thu, 9 Jan 2020 at 21:45, Wim Leflere via Boost <[hidden email]>
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: boost range for non integers

Boost - Dev mailing list
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 <[hidden email]> wrote:

>
>
> On Thu, 9 Jan 2020 at 21:45, Wim Leflere via Boost <[hidden email]>
> 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
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost