Boost logo

Boost :

Subject: Re: [boost] [range] Proposal: addition of front(), back(), at(), operator[]
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-03-23 18:31:29


Adam Wulkiewicz wrote:
> Hi,
>
> Neil Groves wrote:
>> iterator_range already has front() and back() functions. These are
>> not part
>> of the Range Concept since we want to be able to model them
>> non-intrusively. The iterator_range and sub_range classes can be used to
>> wrap other iterator pairs or ranges and provide most of the member
>> functions that you are suggesting.
>
> Thanks for the tip. However I rather see those functions as
> algorithms, not a part of the Concept. They musn't be modeled
> intrusively, just like any other Boost.Range algorithm.
>
> So in the case of iterator_range the use case would look like this:
>
> boost::make_iterator_range(range).front();
> boost::make_iterator_range(range).back();
> boost::make_iterator_range(range)[index];
>
> I'd say it's less intuitive/readable/convenient than:
>
> boost::front(range);
> boost::back(range);
> boost::at(range);
Of course this should be:

boost::at(range, index);

>
> And the readability is what I wanted to achieve but ok, the
> functionality is there. And this way the implementation of operator[]
> is straightforward. Still, I prefer my way :)
>
> Regards,
> Adam


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk