|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-11-03 03:19:24
"Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> "Pavol Droba" <droba_at_[hidden]> wrote in message
> news:20031102123159.GD5136_at_lenin.felcer.sk...
>
>> This seem very convincing :) I will keep the name "iterator_range" and
> support
>> functions will be ranamed to follow.
>
> that's a quick decision :-)
>
> I'm still not convinced that we need more than one range class for anything.
>
> David write:
>> It should only be called "range" if it's meant to work on ranges of
>> non-iterators. But then, you should call it half_open_range ;-)
>
> I don't agree.
That's a quick disagreement :-)
> The current interface seems compatible with any type of ordered
> type:
>
> template< typename T >
> class range
> {
> T begin() const;
> T end() const;
> T size() const;
> bool empty() const;
> };
What is the semantics of end()? If it means "one past the end", it
is not appropriate for closed ranges.
> AFAICT, only size() needs to be specialized for integers which
> should be easy using typetraits. So the same range class can easily
> support both iterators and integers.
What about floating point or rationals?
> Moreover, the standard uses half-open ranges of the type
>
> [begin,end)
>
> where 'begin' is included and 'end' is not. If the argument for not using
> the name range for the class is that many different types of ranges exist,
> then
> we should consider if that is a good thing with these many ranges. IMO, it
> is not a good thing because all the ranges can be used to describe
> eachother:
>
> [begin,end] = [begin, end + 1 )
> (begin, end) = [begin +1, end )
> (begin, end] = [begin + 1, end + 1 )
>
> To me it seems that it shall only be necessary with one type of
> range.
Wrong. Numerics commonly requires fully-closed and sometimes
fully-open ranges.
> Bringing more into the picture will only bring confusion.
Are you sure you're not already confused? ;-)
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk