[boost] Re: Re: String Algo Review Results

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-11-02 23:36:03

"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
news:0f8a01c3a11d$96dc4f50$6501a8c0_at_metacomm.com...
> David Abrahams wrote:
> > Pavol Droba <droba_at_[hidden]> writes:
> > > Is "iterator_range" ok, or should it be renamed to "range"?
> > > There is a set of support utilities, which has currently names like
> > > make_range, copy_range and etc.
> > > Either these functions are renamed to make_iterator_range (and etc.),
> > > or the class will have to be renamed to "range".
> > >
> > > My question to public is: What is prefered solution?
> >
> > It should only be called "range" if it's meant to work on ranges of
> > non-iterators.
>
> Yep. In particular, a general purpose range wouldn't necessarily have
> 'begin'/'end' (for instance, ours here at work doesn't), and if it would,
> they would do quite a different thing.
>
> > But then, you should call it half_open_range ;-)
>
> Not necessarily :). Here's what we have:
>
>     template< typename Tag >
>     struct range_traits
>     {
>         template< typename Range > static typename Range::value_type
> size(Range const&);
>         template< typename Range > static typename Range::value_type
> front(Range const&);
>         template< typename Range > static typename Range::value_type
> back(Range const&);
>     };
>
>     namespace tag {
>     struct half_open;
>     struct closed;
>     }
>
>     template< typename T, typename Tag = tag::half_open >
>     struct range
>     {
>         // use range_traits<Tag> to implement variability aspects of open,
>         // half-open and closed ranges
>         // ...
>     };

It's not clear what's so good about this. Could you tell us?

Thanks

Thorsten