Boost logo

Boost :

Subject: Re: [boost] [range] Proposal: addition of front(), back(), at(), operator[]
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2014-03-23 18:15:51


2014-03-23 20:59 GMT+01:00 Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]>:

> Hi,
>
Hello,

>
> I propose to add the functions described below to the Boost.Range. I found
> the use of those very convenient WRT the corresponding use of begin() and
> end(), and a lot more readable.
>
> 1. front()
> returning the reference to the first element
> precondition (assert): !empty(rng)
>
> return *begin(rng);
>

Usage: front(rng)
+1

>
> 2. back()
> returning the reference to the last element
> precondition (assert): !empty(rng)
>
> For BidirectionalRange
> return *(--end(rng));
>

+1

> For SinglePassRange it could iterate over the range and return the
> reference to the last element
>
-1 for silent O(n), when O(1) is expected for other ranges.

3. at()
> returning the reference to the i-th element of the range
> precondition (throw std::out_of_range or assert): index < size(rng)

-1 for throwing on logic errors; I think "container::at()" is a mistake in
the Standard Library.

For RandomAccessRange
> return *(begin(rng) + index);
>
> For SinglePassRange it could iterate over the range and return the
> required element
>
-1 for silent O(n), when O(1) is expected for other ranges.

For me, non-throwing at() would be more useful however this behavior won't
> be intuitive. So the following should also be provided:
>
> 4. sub(), subscript(), el(), element(), at_index(), at_(), index(),
> indexed(), access(), operator[], ...?

+1 for subscript(rng,n).
-1; for operator[], I'd definitely prefer a named function call.
 The name 'at' would be a perfect name, if it only didn't have the throwing
behavior in the Standard Library.

the implementation of indexing operator[]
> same as 3 but instead of throwing an assert would be used
>
+1

>
> The use of operator[] could be similar to this:
>
> {
> using boost::range::subscript_operator;
> rng[index];
> }
>
> So not very convenient. But maybe you have a better idea?
>

Just a named function call is fine for me.

>
> Regards,
> Adam
>
> Thanks for some interesting ideas, Adam
Regards,
Kris


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